Paket: Freeze paket version

[pedrofelixsky]

Hi,

Is there a way to freeze the paket version that a solution is using?
I would like that everybody working on my project (including the CI) would use the _same_ paket version, independently of the moment where they do the bootstrap.
As an example, the new 3.0.0 version introduces some changes that results in lots of diffs in the files ("spec" removal on the lock file, "netstandard" choice in the csproj). Without freezing the version, this becomes difficult to manage, since I now have different team members using different paket versions with different csproj policies

Gradle supports this with the concept of the Gradle wrapper

[inosik]

http://fsprojects.github.io/Paket/bootstrapper.html

Tell the bootstrapper which version you want to use:

$ .paket/paket.bootstrapper.exe 2.66.10

You can also control this with the environment variable PAKET.VERSION, but the command line parameter overrides this value.

[forki]

yep fix it with the bootsytrapper call.
cheers

[pedrofelixsky]

Thanks for the very quick replies.
I may be missing something, however I do not think that this solves the issue entirely, due to the bootstrapper step being explicit. For instance, if I need to increase the paket patch version number to fix an error, I will need to ask all team members to run the boostrapper again.

A possible solution (inspired in gradlew) would be to create a paketw.bat file with

%~dp0paket.bootstrapper 3.1.8
%~dp0paket %1 %2 %3 %4

that is used instead of paket (e.g. use paketw restore instead of paket restore). This way, I would ensure that the correct version is used by everyone and that version updates are handled transparently.

What do you think? Am I missing something more simpler to handle this?
Thanks

[forki]

We usually call the bootstrapper as part of the build script.
On Jun 22, 2016 11:38 AM, "Pedro Felix" [email protected] wrote:

Thanks for the very quick replies.
I may be missing something, however I do not think that this solves the
issue entirely, due to the bootstrapper step being explicit. For instance,
if I need to increase the paket patch version number to fix an error, I
will need to ask all team members to run the boostrapper again.

A possible solution (inspired in gradlew) would be to create a paketw.bat
file with

%~dp0paket.bootstrapper 3.1.8
%~dp0paket %1 %2 %3 %4

that is used instead of paket (e.g. use paketw restore instead of paket
restore). This way, I would ensure that the correct version is used by
everyone and that version updates are handled transparently.

What do you think? I'm I missing something more simpler to handle this?
Thanks

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/fsprojects/Paket/issues/1747#issuecomment-227693282,
or mute the thread
https://github.com/notifications/unsubscribe/AADgNNFUpocwP7yApOous5nG9BWtuAE1ks5qOQKRgaJpZM4I7i69
.

[cguedes]

Why don't we use something like the engines field in the nodejs' package.json (https://docs.npmjs.com/files/package.json#engines).

We can add something like

paket: 2.66.10

to the paket.dependencies file.

We can/should even use/allow semver to specify the version.

[forki]

Yes this could work, but there are couple of things to consider:

• what happens when you don't have the version?
• What would Paket.VS do (it would probably test internal version of Paket.Core)
• Do we put it into lock file as well?

[cguedes]

I guess we can:

• default to the latest version (as for now, and to not break existing clients)
• I don't know this :-/
• Yes, maybe that can the usefull if we use semver to specify the paktet version

[forki]

no I meant the following:

Suppose you have paket 3.1.2 and it reads paket: > 3.2 from deps file. What should happen?

[pedrofelixsky]

Download paket 3.2 and use it instead?

[cguedes]

I agree.

[forki]

so it should quit itself, patch itself silently and rerun?

[forki]

(that would not work with VS addin)

[forki]

I maked this up-for-grabs and think it can be done in two phase:

Phase 1

• Add a paket version restriction to the deps file and the lock file
• Make paket fail when it doesn't match the given version

Phase 2

• make paket upgrade (or downgrade) itself if it doesn't match the specified restriction