[WIP] Impressions from using Paket Pack API #642
Comments
|
did you see that we already have FAKE tasks? https://github.com/fsprojects/Paket/blob/master/build.fsx#L188 |
|
regarding overwrite of meta-data: that's exactly the pain point we need to figure out. Where would it make sense to add this feature? FAKE tasks or Paket or both? |
|
No I did not 😄 That does seem to solve most issues. Will have a go in the morning. |
|
An other option would be to enable paket.template files to share data in some way (I'm thinking off the top of my head here :) ). Some kind of template template that projects within the solution can override. |
|
Just been trying it out; fell over when using an indirect dependency PackageMetaData line 209 Turns out it was a dependency I didn't need so I have it working. Will try FAKE tasks now! |
|
@JonCanning could you please elaborate? thanks |
|
Sorry, you may have noticed that I'm generally crap at reporting bugs paket.dependencies contains FsPickler.Json, paket.template contains FsPickler |
|
It will assume that if you've got a dependency listed in paket.dependencies that you want it listed explicitly as a dependency of your package. |
|
I'm trying to push to appveyor nuget and it's failing with a 500 error. I've been trying to fix it but am stumped 😢 Any pointers on what I can do to diagnose the problem? |
|
same as #646? |
|
It's something with the nupkg, if I pack with nuget I can push with Paket |
|
@JonCanning really? Any chance you could get us a copy of the nupkg, or is it closed source code? |
|
If you can't send it to us, try opening the nupkg with Nuget Package Explorer and see if that succeeds. |
|
Ah, RTFM Jon I had added a dependency block.... |
|
@JonCanning did that help? It will just ignore the manually specified dependency block in that case. Also, open question to all: if a project template specifies a files or dependencies section, should that be an error? At the moment they will be silently ignored. |
|
Yes, the dependencies are being duplicated |
|
can we close this? |
|
So, @forki 's issue is fixed in #660 . @JonCanning how are things going with AppVeyor? |
|
If it's broken, let's open a new issue for it. |
|
It was fine when I removed the dependency block since they were being duplicated |
|
@JonCanning thanks! |
|
Thanks for this, it has banished nuget completely from our code |
|
I feel like I should get this mounted and put on a wall (possibly with a copy for each Paket maintainer) |
Started working on replacing
Fake.NugetwithPaket.PackThought it might be useful to have the first impression from someone working with this API for the first time. So consider this a braindump. If some of this stuff is to be considered a bug, we should probably create separate issues for them.
Dependencies.Locate().Pack(...)is the correct one to use for this kind of integration.DotNetzipconfusingly nameIonic.Zip.dll. In order for Paket to find and load the DLL. Feels a bit wrong to do this as the script itself does not have any direct dependencies on this DLL. Note: I am note very used to writing F# scrips, and it is possible this is to be expected. If so, it should probably be documented somewhere, (Or maybe be part of the file load exception message given?)ProjectScaffoldexplicitly sets quite a bit of assembly info (https://github.com/fsprojects/ProjectScaffold/blob/master/build.template#L71) None of this seemed to be read by Paket.Pack. Got exception that all mandatory info was lacking, even after checking assemblyinfo.?version:stringparameter to thePackcommand did not seem to have any effect.The text was updated successfully, but these errors were encountered: