composer reinstall vendor/package

[sirsquall]

Hi,

I'm using composer with artifact, where we store all our common modules.

For the moment we are using maven who is building all the zip files, and running all the tests for our commons modules, and it's working pretty well.

So when I go to the project where I want to update my pacakge, composer find no change (normal the version didn't change), so I wanted to lunch a reinstall command instead of removing the package and adding again the package, who is quite borring to do.

So could you make this improvement ?

[stof]

well, why do you need to update the package if it is the same version ?

[sirsquall]

The version number is not handle by the composer.json, we are updating those number through jenkins, to be able to trace all the pipeline.

So in local the number never change, it change only when someone commit, and jenkins build everything.

[stof]

well, where is the project getting the package from ? Something generated locally or by Jenkins ?

[sirsquall]

The project is getting the package locally, during our development, and after is getting from Jenkins.

And when we are developing in local, offen we have to reinstall a given package, so is for that I'm asking for this improvement.

It can be used also for somepeole who are working with the VCS, and they want to reinstall a package, not only with artifact.

I think It could be usefull for a lot of people, just to be able to reinstall a package.

[jrobeson]

and perhaps if you accidentally delete a file/files in vendor and want it to be restored to previous state?

[dsnoeck]

+1. I have a similar workflow and it will be great to have an proposition for that.

[Ejz]

why not rm -rf vendor && composer install

[milkovsky]

why not rm -rf vendor && composer install

Not optimal, especially when you have a lot of packages.

Easier would be
composer remove [vendor/package] && composer require [vendor/package]

Would be good to have
composer reinstall [vendor/package]

[hkdobrev]

@milkovsky

Easier would be
composer remove [vendor/package] && composer require [vendor/package]

Would be good to have
composer reinstall [vendor/package]

You could now do rm -rf vendor/package && composer install it will do just what you want (considering you have the lock file).

[GiantCowFilms]

+1 Reinstall would be nice

[AlexBaitov]

+1 Reinstall
rm -rf .. && composer install is awkward

[zearg]

If some files are missing in your bundle :
rm -rf vendor/"vendorName"/
then run a composer update

But...
:+1: Reinstall shortcut for remove/install

[WadeShuler]

+1 more :)

I am working on an extension locally. I make changes to it, and none of the changes are live until I remove and re-install. This is a tedious process, repeating it over and over. A reinstall option would be much appreciated! I am surprised that this feature isn't already available, and that the response here is "why do you need it". It would take only a minute to add this feature into Composer, it is needed by many, and when you step back and think about it, the feature just makes sense.

Additionally, I think there needs to be a feature to tell composer to use files from somewhere else. So I can make an edit, and those edits are live, instead of having to remove and re-install every time. Real time edits would make working with Composer a lot better.

[NiMeDia]

+1 see @WadeShuler

[skorzh-bs]

+1 for reinstall

[pschirch]

+1

[hkdobrev]

IMHO even if you need reinstalling a package, you could create a simple shell alias for that.

[NiMeDia]

@hkdobrev
Well, we could all build custom scripts for everything by ourself but it is always better to have a native supported and well tested feature in the tool or library you are using. It is not a good practice to solve problems by temporary workarounds which may get obsolete in the next version of the tool.

Another point is that the user could be sure that reinstall does what it is actually build for: reinstalling packages. How should the user know that he must delete the package in the vendor directory and install it again. As @AlexBaitov said:

rm -rf .. && composer install is awkward

Never mentioned that a clean reinstall should maybe invalidate the caches for the package you want to reinstall. Why do other package manager like apt-get have the reinstall flag?

[sirsquall]

@P0rnflake I totally agree with you.

I created this ticket since over a year, I know, this is not the priority.

But instead of trying to find alternatives or homemade temporary solution, I think that this ticket would already be solved long ago.

Almost all the tools have the "--reinstall" I do not understand why there is a debate around this.

If you do not wish to do the reinstall please just close this issue, otherwise implement a "reinstall".

Best regard

[stof]

If you do not wish to do the reinstall please just close this issue, otherwise implement a "reinstall".

If you really want it, you can also contribute to Composer. We are all working on composer in our free time

[NiMeDia]

I think it would be helpful if we could classify the issue as improvement and add it to some kind of milestone with a priority.

In my opinion the frustrating point is that there is an endless discussion whether to do it and why not to do it to prevent effort.

If it's related for the roadmap of composer maybe one of us would implement it.

[hkdobrev]

@P0rnflake I think you mean these milestones - https://github.com/composer/composer/milestones I personally would put it in Nice to have, but the maintainers of Composer would decide that.

[NiMeDia]

@hkdobrev Ye, thats what I meant, just put this issue officially "on the road" so that contributors have a motivation to work on it.

[Seldaek]

Ok so I think a --reinstall flag doesn't make much sense because our install command does not really install a specific package. A reinstall command taking one or more package names probably makes more sense. If anyone contributes it great, but in the meantime please refrain from just writing :+1: here, it doesn't help get things done any faster.

[juanmf]

I agree that a shell alias is an option, but first you loose 30 mins, looking for reinstall, and then remove forces you to revert you composer.json and then update and then reinstall.

[zainengineer]

How about simply rm vendor/composer/installed.json ?

[schmunk42]

We'd also need something like this. Our use case is, that we usually install dist packages, but in many of our projects we also work in _our_ vendor-extensions, which should be git-repos (source) for that matter.

So we currently also use rm -rm vendor/ns1 vendor/ns2 && composer install --prefer-source. The drawback is, that you need to check manually if there are changes in the code already. Composer i.e. warns you, when a source-repo has changes - which is pretty useful.

What about an extra option to define the prefer strategy?

{
  "extra": {
     "prefer-source": {
        "ns1/*",
        "ns2/a-package"  
     }
  }
}

[Seldaek]

What about.. a trip to the documentation? :) https://getcomposer.org/doc/06-config.md#preferred-install

Also composer can not warn you for changes in dist packages, so reinstall wouldn't help anything there.

[schmunk42]

@Seldaek Thanks :) I thought I had seen this "somewhere".

Just one question: A command-line option --prefer-source only takes precedence if the package is configured as auto? Otherwise the value in config wins?

[hkdobrev]

@schmunk42 I think the value on the command line always takes precedence. This way you can have preferred install in the config, but always install with --prefer-dist on production.

[SvenRtbg]

Here's my use case:

During development of an application, the repository of a package gets added to repositories in order to speed up development cycles. But this does not add the dist info to the composer.lock file.

If nothing is done about this, that package will always be cloned during deployment, which takes more time and space. So I'd need a way to update the dist info for a package.

Unfortunately I cannot really do this without some effort. Deleting the whole vendor dir, followed by composer install --prefer-dist will still clone that package, because dist info hasn't been recorded, even if the vcs repository has been removed.

I want to add the dist info for a particular package that is installed in a tagged version as a cloned repo.

I have to do all this:

1. Assuming the application is checked out and dependencies have been installed/cloned.
2. Remove the repository entry
3. Remove the exact folder inside vendor of that package.
4. Run composer update.

The negative side effect: All dependencies get updated.

The problem inside: How can I know the package name of the repository I have to remove?

If I want to do this automatically via script, I'd be forced to scan all vendor folders, find those that are cloned repositories, then run git remote -v to get the URL, then also parse the composer.json in order to find the package name.

Now I can remove the folder, and run composer update vendor/package to selectively only update that package, but I still have an update.

What I'd prefer to do instead:

1. Assuming the application is checked out and dependencies have been installed/cloned.
2. Remove the repository entry
3. Run composer reinstall --prefer-dist.

And Composer would try to find the exact version already installed, and if the information source (packagist.org or local instances) gives a dist location, it would add it to the lock file and swap from cloned to zip-installed vendor folder for this package.

Something that is getting close is that IF I have deleted the vendor folder of that package, running composer update --lock will install the dist version and add the dist info into the lock file. But I still have to find out which folder to delete if I want minimal file operations.

TL;DR:
What I found to be working without unintended updates:

1. Assuming the application is checked out and dependencies have been installed/cloned.
2. Remove the repository entry
3. Remove all the vendor folder.
4. Run composer update --lock.

This will install all the packages again (most likely from cache), explicitly install packages that previously were cloned (due to the direct vcs repository link) as ZIP downloads, and also add the full dist info into the lock file.

So for my usecase the minimum gap between what is there and what is missing is that the proposed reinstall command should act like update --lock after it emptied the vendor folder. Bonus points for omitting unnecessary file operations - the only obvious operation here would be the switch from source to dist for the packages that can support it.

[acuthbert]

When you build libraries in composer projects you start out using dev-[branch] versions. However after you move to tagged version numbers e.g 1.0.0 there is a period where there are still a lot of point releases in the early days of the library package.

The issue I have is that in those early days (and even later on), it's easy to start changing some library code to investigate a fix and before you know it you've made changes in 6 different files to get the fix working. At this point you realise you forgot to remove the project folder in vendor and do --prefer-source. So now you're left with changes in lots of files and no way to list those changes (no git diff) and no way to reapply them.

For me instead of --reinstall, it would be better to have something to manage this very workflow. As I think it needs to actually move the folder to one side, do the clone and then overlay the files back so that the changes are preserved and ready to commit. This is what I do in most cases, I move the folder, composer update --prefer-source, move the files back.

This of course also presupposes that the version now cloned is exactly the same version that you were on previously. it would have to use the lock file version number, otherwise the modified files it would try to preserve would put the project off the rails if it was an old version.

Perhaps this is better as a new composer command?

What about composer prepare-fix vendor/project?

[Seldaek]

@acuthbert looks like you should have a look at https://getcomposer.org/doc/06-config.md#preferred-install and set it to source if you always want source.

[pije76]

+1 for reinstall

[okaufmann]

Delete the folder and require dependency:

rm -Rf vendor/a/package && composer require a/package

[AnrDaemon]

A common use case for me is: I find a library in my project misbehaving, go down to its source and quickly hack something to make it work.
Then I copy the hack into override directory of my project, go over it again to improve on my hack to make it more generic and PR-ready.
Now, I want to return the library to its initial state to know that the hack is loaded before origin. Okay, I know I should probably have copied the hack out earlier, but setting up override is not a good idea until you sure know it can be fixed in first place.
A simple instal --reinstall or equivalent command would greatly simplify my life. And not only mine.

[fubarhouse]

In addition to the argument from @AnrDaemon, it would be ideal to be able to reinstall a package with consideration to the .git folder, ie --prefer-source vs --prefer-dist.

[dakujem]

+1

I've recently run in a situation where I could not use rm command, but I was able to run composer. I ended up having to write a PHP script to delete a repository from vendor and then running composer install. Though this was an emergency situation, it would be much much faster to just run composer reinstall abc/package.

[maglor]

+1

[roygoldman]

Another consideration is that when working with installer plugins, you often get packages installed in different locations, and needing to remember which package was installed where, so you can rm path/to/vendor/package can be tedious, as such having a reinstall command, even if all its doing is resolving the directory and path and removing the contents then effectively running composer install is easy enough and can greatly simplify work flows. As I needed this functionality for a specific use case, I've implemented a plugin which provides a composer reinstall command. The details can be found in the roygoldman/composer-reinstall package.

[sirsquall]

@roygoldman good point

By the way, in 1 month and 3 days is the anniversary of the creation of this post, (5 years now, time fly), what do you think to offer a special gift to all of us, by adding the reinstall option?

[AnrDaemon]

@roygoldman I have a question though. How does your plugin detect how to UNinstall a given package?

[roygoldman]

@AnrDaemon, the plugin usage is detailed in it's readme. The command allows passing one or more package names, composer reinstall vendor/package [vendor2/otherpackage ...]. The files for the specified packages are deleted and then the composer installer is run to re-download the versions based on the lock file.

[AnrDaemon]

Much to your surprise, I did read that README twice before asking my question.
It talking at length about package installation, but has not a single word about prior package removal.

[roygoldman]

I'm a little unclear on your question then. The project doesn't uninstall project (in composer terms), It just deletes the package's files and redownloads the now missing packages. The packages don't need to be removed prior to execution, the command takes care of that.

If you are still unsure of project usage, please open an issue on the project and I will follow up and update the README as needed, I don't want to spam everyone on this thread unnecessarily.

[AnrDaemon]

Oh, so, it just assumes that package files are all in the same directory? Got it.

[roygoldman]

Yes, it assumes the files were all downloaded to a single directory. If there is a common use case otherwise which we should account for, and a way to programmatically determine file locations, I'm happy to account for that in the removal logic.

[rgpublic]

+1 also from me. It is so convenient e.g. with apt that you can just do "apt install --reinstall" if you broke some files in your package. And a remove/require pair is not equivalent because remove might remove dependencies or not even be possible. It would be really great if there was an easy way to just put some files you changed back to their original state.

[XedinUnknown]

Usually, removing the lib and then composer install works well. But in my case, I want to re-install vimeo/psalm. Psalm has a files autoload config, and when I remove it, Composer throws an error, because it can no longer find the files in vendor/vimeo/psalm to load. These paths are stored in vendor/composer autoload files, and do not get removed when you just delete a lib. This problem would manifest for every package that "auto" loads files explicitly.

[ytsurk]

@zainengineer gave the perfect solution (addendum: for me, who just wants to reinstall everything after a long debugging session):

How about simply deleting vendor/composer/installed.json ?

https://github.com/composer/composer/issues/3112#issuecomment-218937369

[rgpublic]

@ytsurk Interesting definition of "perfect". This bug is about having an easy method to reinstall a single package. At least that's what I thought this is about.

[ytsurk]

That's true, it's not perfect for one package. Still the line of the desired package can be removed in _installed.json_, and composer install will re-install it. Which, I admit, is not an easy method .. but I wanted to make it more visible in this thread.