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

local-global repositories (composer link command) #601

Open
fprochazka opened this Issue Apr 19, 2012 · 32 comments

Comments

Projects
None yet
@fprochazka
Contributor

fprochazka commented Apr 19, 2012

Hi,
I'm writting simulatenously few libraries and it's realy pain to commit everything and for every few lines write $ composer update. So it would be nice to have new kind of local repository or something, that wouldn't copy the dependency into project, but rather link to it. So when I change something in one project, it affects the other one immediately and I don't have to commit stuff and run update on composer.

Some command like "link this library, but don't touch it, just autoload it".

Or is there any suggested worflow on this problem?

@Seldaek

This comment has been minimized.

Member

Seldaek commented Apr 19, 2012

There is no way to do it with composer at the moment, obviously you can rm -rf vendor/<some/package> and then symlink your repo back at this place manually. This should work as long as you don't update, if you udpate, I'm honestly not sure what can happen. This voids your warranty :)

@fprochazka

This comment has been minimized.

Contributor

fprochazka commented Apr 19, 2012

I'm pretty sure it wouldn't do anything catastrophic, as long as there are uncommited changes in the repository. I've just bulk replaced something and the IDE replaced it even in the vendor directory. The composer complained than, about the uncommited changes.

I think that is the best behaviour possible! I had my own vendors script inspired by Symfony's vendor script and before this Kdyby/sandbox@3724873 commit, it managed to destroy few days of work :)

So now the question is, could there be added some "create symlink only" respository? I'm not sure if I find time to create a pull request, but I will try.

@Seldaek

This comment has been minimized.

Member

Seldaek commented Apr 19, 2012

I think the way npm does it (see docs: http://npmjs.org/doc/link.html) sounds pretty awesome. If you can copy that entirely, go for it:)

@Seldaek

This comment has been minimized.

Member

Seldaek commented Apr 19, 2012

Then the only thing that should be done is that the installers should check if the package dir is a link, and if so they should leave it alone or warn user or something smart, but not delete it and overwrite with something else, and especially not recurse into the symlink and delete everything.

@pavelkucera

This comment has been minimized.

pavelkucera commented Apr 19, 2012

I would welcome this type of repository too because of the same reasons as @hosiplan. It's always "type a couple of lines, commit them with message á la 'update', run $ composer update... Oh, there's a typo! So, again..." and that is a way too long for development :).

@Seldaek

This comment has been minimized.

Member

Seldaek commented Apr 19, 2012

I agree it can be useful, but do you guys realize you can just go in your vendor directory's clone and just develop in there directly? Install with --prefer-source to make sure you get a clone, and then you just go in vendor/foo/bar, and eventually change the git remote with git remote set-url --push origin <your fork url>.

@fprochazka

This comment has been minimized.

Contributor

fprochazka commented Apr 19, 2012

Well, yes I do, but I find it really paintfull. I tried something like that long ago, when I was using git submodules. It's annoying for so many reasons. I will try to implement the linking into composer and send pull as soon as I can :)

@Seldaek

This comment has been minimized.

Member

Seldaek commented Apr 19, 2012

Alright, I find it quite practical to work directly in the vendor dir for testing changes easily in my application. That said, I'm happy if you work on a link command either way :)

@dantleech

This comment has been minimized.

dantleech commented Feb 12, 2015

This would be a nice feature..

@minutephp

This comment has been minimized.

minutephp commented Jun 9, 2015

Yes, this is a long sought after feature.. right now I'm doing this to get a similar result (see the "Brave new Local Development" part)

http://gos.si/blog/composer-development-with-local-dependencies

@rrajkomar

This comment has been minimized.

rrajkomar commented Jun 19, 2015

@minutephp : What you suggest in your post (which I had already read prior to creating issue #4152) is nice but would only work for the current version you have on your machine (if you switch branches dependencies content get switched as well).
Using the repositories option in the ~/.composer/config.json file, you can achieve the same result, you would also be able to handle branches and tags without issues (when using git, AFAIK it would not work with other VCS, i.e. with svn you can't do it because there's no local repository) but as mentionned in the issue it is not very intuitive.

Maybe a solution would be to have another configuration option that would work the other way around : the global config could override values defined in the project's composer.json

For the moment, since I'm working mainly with git, I can work around the issue with the reposiotires option set only in each developer's config.json (and using the same method on the different servers I use).

@ahuszko

This comment has been minimized.

ahuszko commented Nov 27, 2015

This may help you to improve local package development: http://ahuszko.ghost.io/compact/

@staabm

This comment has been minimized.

Contributor

staabm commented Nov 27, 2015

@Seldaek I think we can close this one, because we have PathRepository now?
https://getcomposer.org/doc/05-repositories.md#path

@Seldaek

This comment has been minimized.

Member

Seldaek commented Nov 27, 2015

No I'd still like to investigate a better solution.. path repo has several issues IMO it's a good simple solution but not really the best.

@Petah

This comment has been minimized.

Contributor

Petah commented Nov 27, 2015

+1

@Seldaek

This comment has been minimized.

Member

Seldaek commented Nov 27, 2015

@Petah there is a subscribe button on the right to avoid spamming people with useless +1s.

@Petah

This comment has been minimized.

Contributor

Petah commented Nov 27, 2015

Thanks 👍

@mreschke

This comment has been minimized.

mreschke commented Nov 27, 2015

The path repo can get tripped up sometimes for odd reasons with versioning...not a bug, just logic I can't figure out. But for me the path repo works amazingly for package development. @Seldaek what are some of the issues you are seeing?

@rudiedirkx

This comment has been minimized.

rudiedirkx commented Jan 10, 2016

As I see it (I'm new) path repo only works for the owner/primary developer, since the location is in the shared composer.json. This should be a dev config IMO, which means another (optional) file that is not shared, like composer-dev.json.

I don't understand at all why the package is symlinked or copied. Why not just read from the source?

#1299 is full of good ideas IMO:

  • separate file
  • no symlinks
  • $autoloader->setPsr4() as a back-up, (which helps me now)

Sorry if I'm repeating discarded/irrelevant ideas.

@rrajkomar

This comment has been minimized.

rrajkomar commented Jan 10, 2016

@mreschke : Actually the path repository type does not match the requirement at all since the idea is not to add another source for the dependencies but simply to be able to tell that on dev machines private packages dependencies should be retrieved locally instead of through the otherwise used composer typed repository. Therefore the project composer.json file structure should not have to suffer changes for this feature support.

@rudiedirkx : Using another file that would not be commited (much in the same way as symfony's parameters.yml file) could be a solution if Composer could prioritize it as the first place it has to look into for packages before the usual (/comitted) composer.json file. Although there would be the composer.lock (if present) mismatch issue to handle as well.

@Seldaek

This comment has been minimized.

Member

Seldaek commented Feb 23, 2016

Another util by @franzliedke that seems to be a good fit for this use case: https://github.com/franzliedke/studio

@franzliedke

This comment has been minimized.

Contributor

franzliedke commented Feb 24, 2016

Thanks for mentioning me, @Seldaek. This is, in fact, precisely the use case that Studio makes possible.

With the latest version of Composer, I can finally prepare the new release and will post a proper announcement on my blog.

@Basster

This comment has been minimized.

Basster commented Feb 25, 2016

Thanks, @Seldaek and @franzliedke. Exactly was I was looking for in #4125. I'm happy now. :)

@b01

This comment has been minimized.

b01 commented May 1, 2017

@Seldaek I'd been having problems with using ~/.composer/config.json "path" method on my Macbook Pro for some strange reason. Using @francisbesset Studio worked with no issue.

@francisbesset

This comment has been minimized.

Contributor

francisbesset commented May 1, 2017

@b01 not me but @franzliedke ;)

@fboutin-pmc

This comment has been minimized.

fboutin-pmc commented May 25, 2017

I was looking for a composer link command as well. Studio looked good but I think it's pretty bloated for what it does. So we finally ended-up with manually make use of Symbolic Links combined with this handy script that re-deploy linked components,

composer run-script post-install-cmd -vvv -- --redeploy

Simply put,

  1. You obviously git clone the COMPONENT repo you want to link to
  2. In the project where you make use of the component, you composer require/install as usual, followed by rm -R vendor/COMPONENT
  3. You link with ln -s FULL_PATH_OF_COMPONENT_REPO vendor/COMPONENT
  4. You run the aforementioned script and voilà!
@rudiedirkx

This comment has been minimized.

rudiedirkx commented May 25, 2017

@fboutin-pmc That's what I do too, but with a global package that maintains the links per project.

@franzliedke

This comment has been minimized.

Contributor

franzliedke commented Jun 2, 2017

@fboutin-pmc Care to explain why you think Studio is bloated? I would obviously love to know how, and if I can change that. I'd say feature-completeness is a bigger problem. ;)

@atrauzzi

This comment has been minimized.

atrauzzi commented Nov 19, 2017

Up front, the requirement of having to define anything in a consuming repository to support link functionality is a little inconvenient. I think that's the beauty of npm link really -- it's part of the ecosystem.

@nerdbeere

This comment has been minimized.

nerdbeere commented Feb 5, 2018

the requirement of having to define anything in a consuming repository to support link functionality is a little inconvenient

I can't stress this enough. I have to admit I'm pretty new to the whole PHP / Composer Ecosystem, but coming from npm, developing packages locally without a proper link command is a real pain for me.

The beauty about npm link is, that it doesn't require any changes to your code. Maybe that's just me, but when I work on a feature I only want to see changes in files that actually belong to this feature.

@iamandrewluca

This comment has been minimized.

@atrauzzi

This comment has been minimized.

atrauzzi commented May 2, 2018

@iamandrewluca - While this symptomatically gets the desired outcome, structurally, it's not great. We need a way to do this without having to alter the composer.json file and risk accidentally committing these overrides.

This is why the major comparison here is to npm link.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment