Is it possible to create packages of differing versions with paket pack?

[eiriktsarpalis]

I own a repo which contains multiple projects that depend on each other, each having its own paket.template file. The version of each nuget release is passed through FAKE using the parsed release notes file, and the package inter-dependencies are correctly registered using the CURRENTVERSION macro.

Consider now the following situation: I just added a new project to the repo which is mostly experimental. I would like to release it on nuget together with its siblings, but I would like to enforce a prerelease suffix on that package specifically. This seems to be impossible at the moment: if I attempt to hard-wire a version number on the specific paket.template it will get overriden by FAKE. At the same time, it seems that the PaketPackParams record in FAKE is global, as opposed to a per-template spec (and curiously enough, the PaketPackParams.TemplateFile property evaluates to null).

Any suggestions?

[forki]

Mhm that's... Interesting ;-)
I have no good idea. But I'm open for changes...
On Nov 27, 2015 6:38 PM, "Eirik Tsarpalis" [email protected] wrote:

I own a repo which contains multiple projects that depend on each other,
each having its own paket.template file. The version of each nuget
release is passed through FAKE using the parsed release notes file, and the
package inter-dependencies are correctly registered using the
CURRENTVERSION macro.

Consider now the following situation: I just added a new project to the
repo which is mostly experimental. I would like to release it on nuget
together with its siblings, but I would like to enforce a prerelease suffix
on that package specifically. This seems to be impossible at the moment: if
I attempt to hard-wire a version number on the specific paket.template it
will get overriden by FAKE. At the same time, it seems that the
PaketPackParams record in FAKE is global, as opposed to a per-template
spec (and curiously enough, the PaketPackParams.TemplateFile property
evaluates to null).

Any suggestions?

—
Reply to this email directly or view it on GitHub
#1265.

[eiriktsarpalis]

One idea would be to have the Packet.Pack lambda execute once for every parsed paket.template found in the repo. The PaketPackParams could thus be augmented with information such as dependencies, description, id, etc. In that case, I could fix my problem with something like

Paket.Pack (fun p -> 
    { p with 
        Version = if p.Id = "Experimental.Lib" then "0.0.1-alpha" else release.NugetVersion })

Obviously this could create problems with backwards compatibility..

[forki]

This sounds good from a fake standpoint. But how would this translate into
the paket cmd call
On Nov 27, 2015 7:06 PM, "Eirik Tsarpalis" [email protected] wrote:

One idea would be to have the Packet.Pack lambda execute once for every
parsed paket.template found in the repo. The PaketPackParams could thus
be augmented with information such as dependencies, description, id, etc.
In that case, I could fix my problem with something like

Paket.Pack (fun p ->
{ p with
Version = if p.Id = "Experimental.Lib" then "0.0.1-alpha" else release.NugetVersion })

—
Reply to this email directly or view it on GitHub
#1265 (comment).

[eiriktsarpalis]

Good point. I guess it would only be possible if the pack command could target/parse individual templates or if paket were used as a library by fake. Not sure what is best here.

[forki]

Templates of type project are always processed together. Maybe we can
something into template instead?
On Nov 27, 2015 7:20 PM, "Eirik Tsarpalis" [email protected] wrote:

Good point. I guess it would only be possible if the pack command could
target/parse individual templates or if paket were used as a library by
fake. Not sure what is best here.

—
Reply to this email directly or view it on GitHub
#1265 (comment).

[eiriktsarpalis]

Perhaps it could be possible to pass separate version id's per project id. This would effectively add a separate command line option

paket pack version 1.1.2 --custom-version Experimental.Lib 0.0.1-alpha --custom-version Another.Experimental.Lib 1.0-beta

which would override the default version number in case the paket.template id matches the first argument of the command. This could be then specified on the FAKE side by adding a CustomVersions : Map<string, string> property to the PaketPackParams record. Not as nice as the lambda approach, but certainly a less intrusive solution given the current state of things. Thoughts?

[forki]

Yes that would work too.
On Nov 28, 2015 17:36, "Eirik Tsarpalis" [email protected] wrote:

Perhaps it could be possible to pass separate version id's per project id.
This would effectively add a separate command line option

paket pack version 1.1.2 --custom-version Experimental.Lib 0.0.1-alpha

which would override the default version number in case the paket.template
id matches the first argument of the command. This could be then specified
on the FAKE side by adding a CustomVersions : Map<string, string>
property to the PaketPackParams record. Not as nice as the lambda
approach, but certainly a less intrusive solution given the current state
of things. Thoughts?

—
Reply to this email directly or view it on GitHub
#1265 (comment).

[forki]

I think this would work, but currently template file type "project"
requires to build all template files together since we need to replace
interproject dependencies in nuget dependencies.

If we fix this then it should work. But then we don't need the exclude
parameter since we could search for *.template and just pack everything in
own step
On Dec 1, 2015 12:15, "Eirik Tsarpalis" [email protected] wrote:

I did a bit of experimentation. In the end I came up with this:
eiriktsarpalis/Paket@638628f
eiriktsarpalis@638628f

It essentially allows the user to explicitly exclude specific project ids
when calling the pack command. From the FAKE point of view, it would solve
my problem like so:

Paket.Pack (fun p ->
{ p with
Version = release.NugetVersion
Excluded = "Experimental.Lib" })

Paket.Pack(fun p ->
{ p with
TemplateFile = "Exprimental.Lib"
Version = 0.0.1-alpha })

Let me know what you think, so that I can proceed with a PR for paket and
FAKE.

—
Reply to this email directly or view it on GitHub
#1265 (comment).

[eiriktsarpalis]

Yes, this is a fundamental flaw in my approach. I deleted my post for that reason.

[forki]

Yeah I guess this is the only fix we need. We need to be able to build
"type project" file independently. Then everything should work with current
fake helpers. Any pr welcome.
On Dec 1, 2015 12:25, "Eirik Tsarpalis" [email protected] wrote:

Yes, this is a fundamental flaw in my approach. I deleted my post for that
reason.

—
Reply to this email directly or view it on GitHub
#1265 (comment).

[eiriktsarpalis]

In general, every approach I have come up with ends up being incorrect under certain scenaria precisely because of interprocess dependencies. I really don't know how this could be fixed without breaking backwards compatibility.

[forki]

Not sure if there is a backward compatibility case we can break here. Building type project template files independently was not supported. I'll look into it

[eiriktsarpalis]

Ok, in the meantime, would you consider merging the exclude parameter? I think it might be useful as a general feature.

[forki]

Yes. We can do this.
On Dec 1, 2015 2:20 PM, "Eirik Tsarpalis" [email protected] wrote:

Ok, in the meantime, would you consider merging the exclude parameter? I
think it might be useful as a general feature.

—
Reply to this email directly or view it on GitHub
#1265 (comment).