I really like the idea of specifying a needed paket version in the deps file. That is a very often requested feature (IIRC we already have an issue for that but I can't find it). But I don't think we should make that a "comment". It's too important. How about this:

version 3.24.1 --prefer-nuget

source https://api.nuget.org/v3/index.json
nuget FAKE
nuget FSharp.Core ~> 4
nuget FSharpLint.MSBuild

or something like that. It would also be interesting to specify version ranges for paket. Someting like version >= 3.23

It'd be great if the version statement would be optional to always get latest (within MaxFileAgeInMinutes).

yes it needs to be optional - also for backwards compat

Using a normal line instead of a comment is conceptually easy and will look cleaner but I need to test compatibility of paket parser itself. I'll add that if it works well.

Ranges are possible but we'll start to duplicate some of the version check logic of paket itself in the bootstrapper. Maybe for a later PR ? 🦊

Absolutely. We don't need that now. Pinning a paket version is already awesome

New version with the syntax suggested by @forki :

version 3.24.1 --prefer-nuget

source https://api.nuget.org/v3/index.json
nuget FAKE
nuget FSharp.Core ~> 4
nuget FSharpLint.MSBuild

Sorry if I didn't get it, but is --prefer-nuget passed in verbatim passed to the bootstrapping that then is paket.exe?

​Alex

http://therightstuff.de/
Tiny phone, tiny mail​

On Oct 27, 2016, 22:16, at 22:16, Julien Roncaglia [email protected] wrote:

New version with the syntax suggested by @forki :

version 3.24.1 --prefer-nuget

source https://api.nuget.org/v3/index.json
nuget FAKE
nuget FSharp.Core ~> 4
nuget FSharpLint.MSBuild

You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#1983 (comment)

@agross The feature is actually completely independent of the "magic" mode where paket.exe is actually the bootstrapper. It's very useful in this mode but could have existed independently of it and would work without it.

What happens is :

• paket.dependencies contains version 1.2.3.4 --prefer-nuget
• User run bootstrapper
• The bootstrapper start and read it's options from all it's sources, including the version line in paket.dependencies, merging them into one set of options. If neither environment variables or the command line specifies a version 1.2.3.4 is used. Prefer nuget is always used as there is no way to disable a flag.
• It then download paket or not as usual (If already present on that version or not)
• User start paket
• Paket read the same paket.dependencies file completely ignoring the version marker

Where it really shine is when you combine this, the --run parameter and the magic mode (That is nothing else than an implicit --run parameter depending on the name of the executable) :

• paket.dependencies contains version 1.2.3.4
• User run paket.exe restore
• The bootstrapper start and read it's options from all it's sources, including the version line in paket.dependencies. If environment variables doesn't specify a version 1.2.3.4 is used.
• It then download paket or not as usual and place it in the temp folder (that's activated by "magic" mode)
• Paket is started with the "restore" parameter.
• Paket read the same paket.dependencies file completely ignoring the version marker

Hm, if --prefer-nuget is always enabled, why do I need to specify it? It looks like a command line parameter to me.

Say for example paket.bootstrapper.exe v2017 supports --fallback <url>. Would it be possible to have something like this in paket.dependencies?

version 1.2.3 --prefer-nuget --fallback http://example.com/paket.exe

Hm, if --prefer-nuget is always enabled

It's not always enabled, what's after version is the same as the command line of the bootstrapper and just treated as another option source.
I was noting that it was always enabled there because the bootstrapper doesn't support negative options (Like an hypothetical --no-prefer-nuget) so once one option source specify that a Boolean is different from it's default there is no way to go back so if paket.dependencies specifies --prefer-nuget there is no way to use github from the command line. (But it's not specific to this change, it already happened before between appsettings and the command line)

Say for example paket.bootstrapper.exe v2017 supports --fallback <url>. Would it be possible to have something like this in paket.dependencies?

Yes, see the code of ArgumentParser.cs in this PR, the line in paket.dependencies is parsed using the new FillNonRunOptionsFromArguments and it's the same function that parses the normal command line. The only difference is that --run isn't possible for the rest of the arguments it's the same code.

The only real complexity is in correctly splitting the arguments into a string[] but that's the role of WindowsProcessArguments.Parse that implements how windows processes normally do it (The OS doesn't provide it and anyway as we want paket.dependencies to be shareable between OSes we must fix ourselves on one algorithm)

@vbfox Alright, now I got it. Thanks!

http://fsprojects.github.io/Paket/dependencies-file.html#Required-Paket-version this OK?

Will announce it soon

Yes 👍

The text could be a little clearer in specifying that the version can be the special "prerelease" string but maybe we don't want to incite users to always get prereleases 😁

please send PRs to make the docs graet again

2016-10-28 15:07 GMT 02:00 Julien Roncaglia [email protected]:

Yes 👍

Maybe the text could be a little clearer in specifying that the version
can be the special "prerelease" string but maybe we don't want to incite
users to always get prereleases 😁

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#1983 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADgNBk0aiQEvA-MMfg5C483V2g5HDPoks5q4fOCgaJpZM4Khssv
.