New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

paket pack ignores specific-version parameter when inserting dependencies making created packages unusable #1321

Closed
mlidbom opened this Issue Dec 20, 2015 · 24 comments

Comments

Projects
None yet
4 participants
@mlidbom

mlidbom commented Dec 20, 2015

Say I have a solution with 3 packages that are packed using specific-version for each package.
A (AssemblyVersion: 3.3.0.0, specific-version: 3.3.0-beta01)
B (AssemblyVersion: 3.1.0.0, specific-version: 3.1.0-beta01, DependsOn: A)
C (AssemblyVersion: 3.5.0.0, specific-version: 3.5.0-beta01, DependsOn: A)

In the created packages the dependency on A in B and C are wrong. They both specify the version: 3.3.0.0 for A instead of the correct 3.3.0-beta01

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 20, 2015

Member

/cc @eiriktsarpalis
On Dec 20, 2015 9:04 AM, "Magnus Lidbom" notifications@github.com wrote:

Say I have a solution with 3 packages that are packed using
specific-version for each package.
A (AssemblyVersion: 3.3.0.0, specific-version: 3.3.0-beta01)
B (AssemblyVersion: 3.1.0.0, specific-version: 3.1.0-beta01, DependsOn: A)
C (AssemblyVersion: 3.5.0.0, specific-version: 3.5.0-beta01, DependsOn: A)

In the created packages the dependency on A in B and C are wrong. They
both specify the version: 3.3.0.0 for A instead of the correct 3.3.0-beta01


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

Member

forki commented Dec 20, 2015

/cc @eiriktsarpalis
On Dec 20, 2015 9:04 AM, "Magnus Lidbom" notifications@github.com wrote:

Say I have a solution with 3 packages that are packed using
specific-version for each package.
A (AssemblyVersion: 3.3.0.0, specific-version: 3.3.0-beta01)
B (AssemblyVersion: 3.1.0.0, specific-version: 3.1.0-beta01, DependsOn: A)
C (AssemblyVersion: 3.5.0.0, specific-version: 3.5.0-beta01, DependsOn: A)

In the created packages the dependency on A in B and C are wrong. They
both specify the version: 3.3.0.0 for A instead of the correct 3.3.0-beta01


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

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 20, 2015

Member

Hi, are templates you are creating of type project or file? I can't reproduce this error in my projects (which are of the former)

Member

eiriktsarpalis commented Dec 20, 2015

Hi, are templates you are creating of type project or file? I can't reproduce this error in my projects (which are of the former)

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 20, 2015

Member

Hmm... Is your code available on github? Or could your provide a minimal repro?

Member

eiriktsarpalis commented Dec 20, 2015

Hmm... Is your code available on github? Or could your provide a minimal repro?

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 20, 2015

The code is available, but anything but minimal :)
I created a branch to try and make it easy for you to have a look at it: https://github.com/mlidbom/Composable.Monolithic/tree/paket-pack-bug-repro

In the root folder you will find repro-paketpack-bug.ps1
If you are in powershell with the visual studio tools in your environment you can just run that file from the folder it is in. If not the code in it should make it easy to figure out what to to to make the repro.

Thanks for the quick response!

mlidbom commented Dec 20, 2015

The code is available, but anything but minimal :)
I created a branch to try and make it easy for you to have a look at it: https://github.com/mlidbom/Composable.Monolithic/tree/paket-pack-bug-repro

In the root folder you will find repro-paketpack-bug.ps1
If you are in powershell with the visual studio tools in your environment you can just run that file from the folder it is in. If not the code in it should make it easy to figure out what to to to make the repro.

Thanks for the quick response!

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 21, 2015

Member

I think, and @forki correct me if I'm wrong in this, that inter-project dependencies need to be specified explicitly in your paket.template files. If Composable.CQRS depends on Composable.Core, you need to add a reference to Composable.CQRS with the CURRENTVERSION macro set.

Member

eiriktsarpalis commented Dec 21, 2015

I think, and @forki correct me if I'm wrong in this, that inter-project dependencies need to be specified explicitly in your paket.template files. If Composable.CQRS depends on Composable.Core, you need to add a reference to Composable.CQRS with the CURRENTVERSION macro set.

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 21, 2015

If I don't use specific-version everything works correctly.

The documentation has this to say: https://fsprojects.github.io/Paket/template-files.html

This template file will create a nupkg: - Named Test.Paket.Package.[Version].nupkg - Version, Author and Description from assembly attributes - Containing $(OutDir)$(ProjectName).* (all files matching project name in the output directory) directory in the lib directory of the package. - Referencing all packages referenced by the project. - Package references - Project references, for projects in the sln that has paket.template files.

Note the last part:

Package references - Project references, for projects in the sln that has paket.template files.

mlidbom commented Dec 21, 2015

If I don't use specific-version everything works correctly.

The documentation has this to say: https://fsprojects.github.io/Paket/template-files.html

This template file will create a nupkg: - Named Test.Paket.Package.[Version].nupkg - Version, Author and Description from assembly attributes - Containing $(OutDir)$(ProjectName).* (all files matching project name in the output directory) directory in the lib directory of the package. - Referencing all packages referenced by the project. - Package references - Project references, for projects in the sln that has paket.template files.

Note the last part:

Package references - Project references, for projects in the sln that has paket.template files.

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 21, 2015

Member

I was not aware of this functionality. It might possibly be a later addition. It's clear that the specific-version implementation does not take this functionality into consideration.

Member

eiriktsarpalis commented Dec 21, 2015

I was not aware of this functionality. It might possibly be a later addition. It's clear that the specific-version implementation does not take this functionality into consideration.

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 21, 2015

Not easy to take something into account if you did not know it existed :)
Do you figure there will be a fix any time soon?

I'll take this opportunity to give everyone involved with paket a big high five. Everything seems so well thought out. Including specific-version. So far, whenever I think "I would like it to work like this" I just look in the docs and what I want is already there :)

After years of tearing my hair out in frustration with NuGet paket is here to save the day.
Big kudos to everyone involved in building this wonderful tool!

mlidbom commented Dec 21, 2015

Not easy to take something into account if you did not know it existed :)
Do you figure there will be a fix any time soon?

I'll take this opportunity to give everyone involved with paket a big high five. Everything seems so well thought out. Including specific-version. So far, whenever I think "I would like it to work like this" I just look in the docs and what I want is already there :)

After years of tearing my hair out in frustration with NuGet paket is here to save the day.
Big kudos to everyone involved in building this wonderful tool!

@inosik

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Dec 21, 2015

Contributor

Try adding an the id parameter to your templates for now, even to the type project ones. There seems to be an issue with project dependencies if there is no explicit id.

I think we need to infer the id earlier, if it's not set explicitly in paket.template.

Contributor

inosik commented Dec 21, 2015

Try adding an the id parameter to your templates for now, even to the type project ones. There seems to be an issue with project dependencies if there is no explicit id.

I think we need to infer the id earlier, if it's not set explicitly in paket.template.

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 22, 2015

@inosik That did indeed make it work correctly. I newer would have guessed that would be a workaround! That will let me abandon my current workaround until we get a real fix. Thank you :)

@eiriktsarpalis Is that a real fix I spy there?

mlidbom commented Dec 22, 2015

@inosik That did indeed make it work correctly. I newer would have guessed that would be a workaround! That will let me abandon my current workaround until we get a real fix. Thank you :)

@eiriktsarpalis Is that a real fix I spy there?

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 22, 2015

Member

@mlidbom yeah, it fixes the issue at least in my reproduction of it.

Member

eiriktsarpalis commented Dec 22, 2015

@mlidbom yeah, it fixes the issue at least in my reproduction of it.

@forki forki closed this in b07ec1a Dec 22, 2015

forki added a commit that referenced this issue Dec 22, 2015

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 22, 2015

Member

@eiriktsarpalis thanks for taking care of this

Member

forki commented Dec 22, 2015

@eiriktsarpalis thanks for taking care of this

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 23, 2015

Hmm, I'm afraid that I still have the problem with 2.38.0.
Pull the latest from my repro branch(instructions above) to see the problem in action.

mlidbom commented Dec 23, 2015

Hmm, I'm afraid that I still have the problem with 2.38.0.
Pull the latest from my repro branch(instructions above) to see the problem in action.

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 23, 2015

Member

Did you try following @inosik's suggestion?

Member

eiriktsarpalis commented Dec 23, 2015

Did you try following @inosik's suggestion?

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 23, 2015

Yes. My development branch uses the workaround of specifying id manually, so there is no great hurry to fix this on my behalf :)

But it is still broken unless you manually specify id. Unless I'm missing something.

mlidbom commented Dec 23, 2015

Yes. My development branch uses the workaround of specifying id manually, so there is no great hurry to fix this on my behalf :)

But it is still broken unless you manually specify id. Unless I'm missing something.

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 23, 2015

Eventually having this working will be kind of important to me though.
We will be migrating dozens of repositories to paket sometime reasonably soon.
Each of those creates a number of nuget packages and consumes many nuget packages created from the other repositories. In total I think we are talking around 100 different packages.

The simpler and the more standardized we can keep the template files the better. I would really like it if we can keep them all to a single identical line: type project

mlidbom commented Dec 23, 2015

Eventually having this working will be kind of important to me though.
We will be migrating dozens of repositories to paket sometime reasonably soon.
Each of those creates a number of nuget packages and consumes many nuget packages created from the other repositories. In total I think we are talking around 100 different packages.

The simpler and the more standardized we can keep the template files the better. I would really like it if we can keep them all to a single identical line: type project

@eiriktsarpalis

This comment has been minimized.

Show comment
Hide comment
@eiriktsarpalis

eiriktsarpalis Dec 23, 2015

Member

I'm not sure why this happens. @forki at what stage does the inference of project id occur?

Member

eiriktsarpalis commented Dec 23, 2015

I'm not sure why this happens. @forki at what stage does the inference of project id occur?

@inosik

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Dec 23, 2015

Contributor

It seems to occur when there is no id and no AssemblyInformationalVersion attribute. Paket then picks the version from the AssemblyVersion attribute, which doesn't allow prerelease information. This is what we see with @mlidbom's project.

I got a repro case here: repro.zip.txt. A and C depend on B.

  1. Run FAKE with -ev OutputDir without-id
  2. Remove the comment in B.csproj.paket.template
  3. Run FAKE with -ev OutputDir with-id

Note that the CURRENTVERSION macro works as expected in both cases for A.

Contributor

inosik commented Dec 23, 2015

It seems to occur when there is no id and no AssemblyInformationalVersion attribute. Paket then picks the version from the AssemblyVersion attribute, which doesn't allow prerelease information. This is what we see with @mlidbom's project.

I got a repro case here: repro.zip.txt. A and C depend on B.

  1. Run FAKE with -ev OutputDir without-id
  2. Remove the comment in B.csproj.paket.template
  3. Run FAKE with -ev OutputDir with-id

Note that the CURRENTVERSION macro works as expected in both cases for A.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 28, 2015

Member

@inosik I tried to run your example, but don't understand the issue yet.
What are you seeing after step 3 and what would you expect to happen instead?

Member

forki commented Dec 28, 2015

@inosik I tried to run your example, but don't understand the issue yet.
What are you seeing after step 3 and what would you expect to happen instead?

@forki forki reopened this Dec 28, 2015

@inosik

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Dec 28, 2015

Contributor

The difference is in the unpacked C.nuspec. The resulting file after step nr. 1 contains

<dependencies>
  <dependency id="B" version="4.5.6.0" />
</dependencies>

while the file after step nr. 2 and 3 contains

<dependencies>
  <dependency id="B" version="4.5.6" />
</dependencies>

The version of the dependency doesn't come from the specific-version argument, but from the AssemblyVersion attribute in step nr. 1.

After steps nr. 2 and 3 C.nuspec should look the same.

Contributor

inosik commented Dec 28, 2015

The difference is in the unpacked C.nuspec. The resulting file after step nr. 1 contains

<dependencies>
  <dependency id="B" version="4.5.6.0" />
</dependencies>

while the file after step nr. 2 and 3 contains

<dependencies>
  <dependency id="B" version="4.5.6" />
</dependencies>

The version of the dependency doesn't come from the specific-version argument, but from the AssemblyVersion attribute in step nr. 1.

After steps nr. 2 and 3 C.nuspec should look the same.

@inosik

This comment has been minimized.

Show comment
Hide comment
@inosik

inosik Dec 28, 2015

Contributor

Sorry, what I meant was, the version should be 4.5.6 in both cases.

Contributor

inosik commented Dec 28, 2015

Sorry, what I meant was, the version should be 4.5.6 in both cases.

@forki forki closed this in 8a76179 Dec 28, 2015

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 28, 2015

Member

should be fixed now

Member

forki commented Dec 28, 2015

should be fixed now

@mlidbom

This comment has been minimized.

Show comment
Hide comment
@mlidbom

mlidbom Dec 31, 2015

I just tried this again on my repro branch and I can confirm that it seems to be working perfectly now.
Thank you both very much :)

mlidbom commented Dec 31, 2015

I just tried this again on my repro branch and I can confirm that it seems to be working perfectly now.
Thank you both very much :)

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Dec 31, 2015

Member

Awesome.

Member

forki commented Dec 31, 2015

Awesome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment