Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not working with custom composer repository (toran) #72

Open
FlxPeters opened this issue Dec 8, 2016 · 4 comments
Open

Not working with custom composer repository (toran) #72

FlxPeters opened this issue Dec 8, 2016 · 4 comments

Comments

@FlxPeters
Copy link

Hi,

i have a Toran proxy for my custom bundles included via repositories which also inclues a package i want to load with studio:

 "repositories": [
    {
      "type": "composer",
      "url": "http://toran.local/repo/private/"
    }
  ],

When i run composer update for my package, i always get the package from toran instead of studio. Studio is loaded properly.

Running 1.2.0 (2016-07-19 01:28:52) with PHP 5.6.24 on Darwin / 15.6.0
[Studio] Loading path /projects/PHP/my-bundle
Reading ./composer.lock
...

Loading composer repositories with package information
Executing command (/projects/PHP/my-bundle/): git branch --no-color --no-abbrev -v
Executing command (/projects/PHP/my-bundle/): git log -n1 --pretty=%H
Writing /.composer/cache/repo/http---toran.local-repo-private/packages.json into cache
Writing /.composer/cache/repo/https---packagist.org/packages.json into cache
Updating dependencies (including require-dev)

It seams to load the package with studio, but then toran also gives me the package. Is this right or how could i force composer to use my studio linked package?

Thanks,
Felix

@FlxPeters FlxPeters changed the title Not working with custom composer repositoty Not working with custom composer repository (toran) Dec 8, 2016
@rask
Copy link
Contributor

rask commented Dec 16, 2016

Are you using tags or branch names with Toran? There are a few issues with external sources being preferred when the local Studio-ised copy and the remote are sitting on the same commit, branch or tag.

See what happens when you

  1. Checkout develop on your local copy of the package and require dev-develop in your composer.json
  2. Configure Toran to only serve tagged releases (haven't used Toran so not sure how it goes).

@emodric
Copy link
Contributor

emodric commented Jan 27, 2017

I ran into the same issue, Composer favors our Satis tagged release over the local Studio loaded one.

@entr
Copy link

entr commented Feb 1, 2017

I had similar problem. Turns out studio only picks my loaded local package only if it doesn't have local git changes (stuff I left unstaged). That said try stashing the package changes before doing composer update and simply pop them after successful symlink.

Nope, scratch that. I just had some bizarre dependency incompatibility.

franzliedke added a commit that referenced this issue Dec 2, 2017
This is a fundamental rewrite of the Composer integration. Now, instead
of adding the loaded paths to Composer's search path (by creating path
repositories for them), we replace the packages downloaded by Composer
that can be found in the loaded paths by symlinks to the local paths.

Doing so requires us to hook into the autoload dumper, which now has to
respect the rules in the local path, not those obtained from Packagist.

All of this should hopefully fix several issues, most importantly:
- Composer's lock file will be written before Studio does its magic,
  therefore not causing any conflicts with other developers' setups.
- Different version constraints on symlinked packages won't cause
  problems anymore. Any required packages that are found in loaded paths
  will be loaded, no matter the branch or version they are on.

Open questions:
- How should packages be handled that have not yet been added to
  Packagist? (Proposed solution: Create path repositories for the loaded
  paths, but *append* them instead of *prepending*, so that they will
  only be used as fallback, if Packagist does not yield any results.)
- Should we validate the constraints from composer.json before creating
  symlinks? With this setup, everything might be working locally, but
  not when downloading the package from Packagist (as another version
  may be downloaded instead).

Refs #52, #58, #65, #72.
@franzliedke
Copy link
Owner

Please try out the newly released 0.14.0-beta1 version. I am hoping this issue will be gone.

(Note that you will have to run composer update and composer dump-autoload for the installation of any package.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants