Repository navigation
Problem updating packages (from component group using -g flag) since https://github.com/fsprojects/Paket/pull/2927 #3017
Description
Description (updated)
update: Just to specify, the referenced packages below are in a specific component subgroup and any references below to "update" are not plain updates, they are updates of a specific component group, example: paket.exe update -g [TheSubGroupName]
When performing a paket update, if there is a lock file present and it contains references to versions that are no longer available remotely, the update appears to work correctly, however, examination of the packages and .lock file demonstrate that the latest available package has not in fact been downloaded.
Repro steps
We actually went through the entire version history of paket from latest to the version that no longer has this issue and pinpointed that it is caused by code in #2927
In our environment, we have a proget server with a new version of a package (say version x.x.14) and the last updated version in the .lock file refers to x.x.13. This package is a transitive dependency that is pulled from a second package whose reference in the lockfile (version referenced) is quite old and no longer available on the proget server. performing packet update does not successfully update the transitive dependency and no error is displayed. so:
1: have a project that has a dependency to a package (no version lock, always latest) with a transitive dependency to another package.
2: ensure the lock file refers to both packages (direct dependency version x.x.1, transitive version x.x.1)
3: update the transitive package in a way that a new version is now available remotely (version x.x.2 or greater)
4:update the direct dependency and remove the older version from the remote server (version x.x.1 no longer available, version > x.x.1 is now the latest)
5:perform a packet update
Repro steps (alternate behaviour observed)
1: have a project that has a dependency to a package (no pinned version, always latest, we will call this package DirectPack) with a transitive dependency to another package (we will call this TransPack).
2: They both need to be in a component group, we will call this ComponentGroupName
3: Do a complete paket update (no -g) to generate a .lock file that has references to the latest available versions of DirectPack and TransPack (lets call these versions 1.0.5 for both)
4: Edit the paket.lock file so that TransPack is referencing an older version (1.0.4, for example) this version CAN exist remotely, which is different from the repro steps originally mentionned.
5: perform a paket update for the component group (paket.exe update -g ComponentGroupName)
6: notice that the TransPack dependency did not get updated to the latest version (1.0.5), and is still at version 1.0.4 (from step 4) which is incorrect.
Expected behavior
both dependencies are now referencing the latest available version from the server (> x.x.1)
Actual behavior
result: no update done on the transitive dependency (lockfile still referencing version x.x.1)
Known workarounds
use a version of paket prior to those containing #2927
Activity
forki commentedon Jan 30, 2018
so you are deleting packages? why?
nukeme1 commentedon Jan 31, 2018
Package retention policy, related to storage space in our case, we only keep about 10 versions back.
nukeme1 commentedon Feb 6, 2018
Is there any news in regards to this issue, it is plaguing our CI environment which is currently set up to use the latest paket version available.
forki commentedon Feb 7, 2018
nukeme1 commentedon Feb 7, 2018
How would one go about simply keeping packages forever? We have well over a million LOC as well as a multitude of packages that can vary in size up to roughly 300 Mb. We host all this ourselves, so infinite storage is really not an option. Having a somewhat modest package retention policy has worked for the past 3 years without issue until now, is there no way to fall back on previous behavior if a remote package version is simply no longer available? I can understand the lack of time, but I hope that you can appreciate our situation considering that this was simply not an issue before this change was made.
forki commentedon Feb 7, 2018
nukeme1 commentedon Feb 7, 2018
Thanks for the response, we use proget and package retention policy is a standard feature, so stating that packages should never. be. deleted. ever. seems a little off. Especially in environments where storage is limited and considering that proget has an option for package retention, this means that it is not something that is custom/unheard of and is actually used/planned for and paket should normally be resilient in this regard since it is an available and useful configuration.
As for pinning the paket version, I have done exactly that for my workstation, however, our CI tries to stay current for obvious reasons so that is not really an option at the moment. The workaround we are currently employing involves manually updating the .lock file at each and every commit to avoid having stale references that cause this issue to occur. Again, thanks for your time, and please consider that this is a situation that should normally be expected/planned for in paket's logic.
forki commentedon Feb 8, 2018
This project has some opinions about package management. One is that things need to be reproducible. That feature of proget is something that this project is considering a real anti pattern.
Not pinning paket in CI is also something that is not recommended. You should usually do that do that you have reproducibility on all levels.
Again, I will look into this soon, but that does not change the fact that paket was designed for reproducible builds and the described workflow above is not recommended - even if other tools do it like that.
forki commentedon Feb 8, 2018
One technical question: what happens when you do "paket update -f"?
Full update should not prefer versions - fixes #3017
forki commentedon Feb 8, 2018
Ok I looked into the referenced commit. I don't think that's the root cause. The commit was fixing a regression and looks correct.
I believe the following is what happens:
For "paket install" we try to keep the new lock file as close as possible to the old lock file. Therefore we keep a list of the old versions as "preferred" versions. This preferred version list acts like a cache. So there the first thing is to make sure -f flag invalidates this cache. That's why it would be good to know if "paket update -f" would generate a valid lock file for you.
The second thing is: for "paket update" we should not use the preferred versions at all. In "update" we want to move all versions forward as far as possible - keeping preferred versions would negate that. In #3031 I did a change for that. I believe this would be the correct fix.
Anyway, please try "paket update -f" so that we know if we need to patch force mode as well.
nukeme1 commentedon Feb 8, 2018
I will try the - f, and get back to you. Our ci does a paket restore followed by packet update - g OurComponentGroup. We walked back from the latest version of paket and reset our folders, downloaded a version and tested it. We did this for each change until the update worked as expected. Even if it looks OK, I can assure you that the problem starts with the referenced change.
Update: we have the same issue with the -f. I'm testing the fix now, will confirm if it is sufficient.
forki commentedon Feb 8, 2018
nukeme1 commentedon Feb 8, 2018
We tested with the version provided (pulled and built the change you referenced) and do not see a difference in behaviour (the paket.exe update behaviour was not faulty to our knowledge). Our build process really starts by calling a paket.exe restore followed by a paket.exe update -g OurComponentGroup. The problem seems to be specific to attempting updates for a specific component group.
We use paket for our release as well as our development builds. Release builds will be kept forever and are separate from the development build lifecycle. Development builds are triggered every change to our code that is merged, so it quickly adds up, that is why we only keep a certain fixed amount of builds on those feeds (the most recent builds being the only relevant ones for our needs).
I updated the issue name and description to further clarify the issue.
Please take note of the alternative repro steps provided to see how to reproduce the issue, it occurs even when the remote package is available in that case
forki commentedon Feb 8, 2018
[-]Problem updating packages since https://github.com/fsprojects/Paket/pull/2927[/-][+]Problem updating packages (from component group using -g flag) since https://github.com/fsprojects/Paket/pull/2927[/+]forki commentedon Feb 8, 2018
ok. disabled preferred versions for "update -g" as well in the PR. Would appreciate another test from your end. Thanks
nukeme1 commentedon Feb 8, 2018
Sorry for the delay, took me awhile to figure that I could just point my remote to the repo and directly have access to the pr, I have built the changes and will confirm if this fixes the issue. The changes do appear to fail in the appveyor and travis builders though, I imagine some tests might need to change for this to pass?
nukeme1 commentedon Feb 8, 2018
I can confirm that the problem is resolved with your latest change!