Question about 'pack' #1414

Closed
dcorriveau-omniscient opened this Issue Jan 19, 2016 · 13 comments

Comments

Projects
None yet
3 participants
@dcorriveau-omniscient
Contributor

dcorriveau-omniscient commented Jan 19, 2016

I'm trying to create Nuget packages using Paket and I'm having a few issues. For one project, when I use a template and set it to "project", the output assembly isn't added to the package (maybe I should look at the code to see how it infers what should be the output assembly).

So since it didn't work for me I thought I'd switch to a "file" template. I managed to make it work by specifying the assembly and the info but I'm wondering why can't paket infer the basic info from the AssemblyInfo, just like it does for a "project" template ? For example, why do I need to specify the id, version, etc. ? I'd like to be able to specify the files I want in lib, but I would like paket to use default values from AssemblyInfo if they aren't declared. I'm guessing it's a design choice but I'm not sure why it's working that way ? Also, is there something special about the "copyright" field, since title, id, company, etc. can be inferred from the AssemblyInfo but "AssemblyCopyright" isn't used for the Copyright info ?

Thanks.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 19, 2016

Member

Inference happens only in type project.
On Jan 19, 2016 9:43 PM, "dcorriveau-omniscient" notifications@github.com
wrote:

I'm trying to create Nuget packages using Paket and I'm having a few
issues For one project, when I use a template and set it to "project", the
output assembly isn't added to the package (maybe I should look at the code
to see how it infers what should be the output assembly)

So since it didn't work for me I thought I'd switch to a "file" template I
managed to make it work by specifying the assembly and the info but I'm
wondering why can't paket infer the basic info from the AssemblyInfo, just
like it does for a "project" template ? For example, why do I need to
specify the id, version, etc ? I'd like to be able to specify the files I
want in lib, but I would like paket to use default values from AssemblyInfo
if they aren't declared I'm guessing it's a design choice but I'm not sure
why it's working that way ? Also, is there something special about the
"copyright" field, since title, id, company, etc can be inferred from the
AssemblyInfo but "AssemblyCopyright" isn't used for the Copyright info ?

Thanks


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

Member

forki commented Jan 19, 2016

Inference happens only in type project.
On Jan 19, 2016 9:43 PM, "dcorriveau-omniscient" notifications@github.com
wrote:

I'm trying to create Nuget packages using Paket and I'm having a few
issues For one project, when I use a template and set it to "project", the
output assembly isn't added to the package (maybe I should look at the code
to see how it infers what should be the output assembly)

So since it didn't work for me I thought I'd switch to a "file" template I
managed to make it work by specifying the assembly and the info but I'm
wondering why can't paket infer the basic info from the AssemblyInfo, just
like it does for a "project" template ? For example, why do I need to
specify the id, version, etc ? I'd like to be able to specify the files I
want in lib, but I would like paket to use default values from AssemblyInfo
if they aren't declared I'm guessing it's a design choice but I'm not sure
why it's working that way ? Also, is there something special about the
"copyright" field, since title, id, company, etc can be inferred from the
AssemblyInfo but "AssemblyCopyright" isn't used for the Copyright info ?

Thanks


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

@dcorriveau-omniscient

This comment has been minimized.

Show comment
Hide comment
@dcorriveau-omniscient

dcorriveau-omniscient Jan 19, 2016

Contributor

I know, but I'd like to understand the design choice behind that, since that suggests my workflow might not be right.

Contributor

dcorriveau-omniscient commented Jan 19, 2016

I know, but I'd like to understand the design choice behind that, since that suggests my workflow might not be right.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 19, 2016

Member

You can pack everytthing into the file type. We cannot know what stuff. Just look at packages like FAKE or the Paket package itself. We only have tools in these - no libs. They might not even be .NET libs.

Even if we have .NET libs in it - which one would we take?

It just no made for that.

Member

forki commented Jan 19, 2016

You can pack everytthing into the file type. We cannot know what stuff. Just look at packages like FAKE or the Paket package itself. We only have tools in these - no libs. They might not even be .NET libs.

Even if we have .NET libs in it - which one would we take?

It just no made for that.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 19, 2016

Member

The interesting question is: why does project type not work. Maybe you ran into a bug.

Member

forki commented Jan 19, 2016

The interesting question is: why does project type not work. Maybe you ran into a bug.

@dcorriveau-omniscient

This comment has been minimized.

Show comment
Hide comment
@dcorriveau-omniscient

dcorriveau-omniscient Jan 19, 2016

Contributor

Ok so your main usage for a file type are packages that contain misc stuff, that aren't .net projects most of the time. That makes sense.

I'll have to debug the project type then, as it seems that's what would be best suited for me.

Contributor

dcorriveau-omniscient commented Jan 19, 2016

Ok so your main usage for a file type are packages that contain misc stuff, that aren't .net projects most of the time. That makes sense.

I'll have to debug the project type then, as it seems that's what would be best suited for me.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 19, 2016

Member

Yes. Also content packages that do not contain any binary data at all
On Jan 19, 2016 9:51 PM, "dcorriveau-omniscient" notifications@github.com
wrote:

Ok so your main usage for a file type are packages that contain misc
stuff, that aren't .net projects most of the time. That makes sense.

I'll have to debug the project type then, as it seems that's what would be
best suited for me.


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

Member

forki commented Jan 19, 2016

Yes. Also content packages that do not contain any binary data at all
On Jan 19, 2016 9:51 PM, "dcorriveau-omniscient" notifications@github.com
wrote:

Ok so your main usage for a file type are packages that contain misc
stuff, that aren't .net projects most of the time. That makes sense.

I'll have to debug the project type then, as it seems that's what would be
best suited for me.


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

@pms1969

This comment has been minimized.

Show comment
Hide comment
@pms1969

pms1969 Jan 19, 2016

Contributor

For me, project types only really work when the paket.template file is named after the csproj. I.e. I have a project called a.csproj with an a.csproj.paket.template file.

Might also just be my useage. Also, you cannot place the template name on the command line. You must call paket either from a super directory with no template specified, or from the directory containing the csproj file, also without specifying the template name.

Contributor

pms1969 commented Jan 19, 2016

For me, project types only really work when the paket.template file is named after the csproj. I.e. I have a project called a.csproj with an a.csproj.paket.template file.

Might also just be my useage. Also, you cannot place the template name on the command line. You must call paket either from a super directory with no template specified, or from the directory containing the csproj file, also without specifying the template name.

@dcorriveau-omniscient

This comment has been minimized.

Show comment
Hide comment
@dcorriveau-omniscient

dcorriveau-omniscient Jan 19, 2016

Contributor

Not sure if I fully understand the templatefile argument. I thought it was used to specify a template file so that it would limit the packaging to that project only (the one that corresponds to the template file).

If I don't use that argument, both packages for both projects in the solution are created successfully, otherwise, the package is created but it doesn't contain the dll.

Contributor

dcorriveau-omniscient commented Jan 19, 2016

Not sure if I fully understand the templatefile argument. I thought it was used to specify a template file so that it would limit the packaging to that project only (the one that corresponds to the template file).

If I don't use that argument, both packages for both projects in the solution are created successfully, otherwise, the package is created but it doesn't contain the dll.

@pms1969

This comment has been minimized.

Show comment
Hide comment
@pms1969

pms1969 Jan 19, 2016

Contributor

run paket from the project's directory.. I'm not sure I understand it either, but that just works for me.....

Contributor

pms1969 commented Jan 19, 2016

run paket from the project's directory.. I'm not sure I understand it either, but that just works for me.....

@dcorriveau-omniscient

This comment has been minimized.

Show comment
Hide comment
@dcorriveau-omniscient

dcorriveau-omniscient Jan 19, 2016

Contributor

@pms1969 You are right, if I run it from the project directory without the argument it works and generate only that package. If I run it from the project directory with the argument it doesn't work (the package isn't valid)...
Thanks for you help.

Contributor

dcorriveau-omniscient commented Jan 19, 2016

@pms1969 You are right, if I run it from the project directory without the argument it works and generate only that package. If I run it from the project directory with the argument it doesn't work (the package isn't valid)...
Thanks for you help.

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 20, 2016

Member

so what's the concrete bug?

Member

forki commented Jan 20, 2016

so what's the concrete bug?

@pms1969

This comment has been minimized.

Show comment
Hide comment
@pms1969

pms1969 Jan 20, 2016

Contributor

As far as I can tell, if you supply a template name, project types don't pack correctly (i.e. the project output (dll) isn't included)

Contributor

pms1969 commented Jan 20, 2016

As far as I can tell, if you supply a template name, project types don't pack correctly (i.e. the project output (dll) isn't included)

@forki

This comment has been minimized.

Show comment
Hide comment
@forki

forki Jan 20, 2016

Member

can you please create a repro case?

Member

forki commented Jan 20, 2016

can you please create a repro case?

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