Skip to content
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

2148: Add dotnet nuget push command and arguments #2229

Merged

Conversation

atlemann
Copy link
Contributor

Add dotnet nuget push command

Fixes: #2148

@atlemann atlemann changed the title [WIP] 2148: Add dotnet nuget push command and arguments 2148: Add dotnet nuget push command and arguments Dec 28, 2018
@matthid
Copy link
Member

matthid commented Jan 10, 2019

Question is if we can somehow re-use existing code. Similar to how we did in msbuild. Basically dotnet msbuild is CLI equivalent to msbuild.exe. The same is true for dotnet nuget and nuget.exe.... Ideally we update them together and not have to fix bugs twice...

@matthid matthid changed the base branch from master to release/next January 12, 2019 16:22
@atlemann
Copy link
Contributor Author

Yes, it would be nice to share some code. I can't seem to find what code is shared between msbuild and dotnet msbuild though.

@matthid
Copy link
Member

matthid commented Jan 29, 2019

Fake.DotNet.Cli references Fake.DotNet.MSBuild: https:/fsharp/FAKE/blob/e7e562866510351452427c3a13833fd4d6bf9f89/src/app/Fake.DotNet.Cli/Fake.DotNet.Cli.fsproj#L25

And some refactoring was done to use a common structure (in order to convert between old and new structure and have a single logic):
https:/fsharp/FAKE/blob/e7e562866510351452427c3a13833fd4d6bf9f89/src/app/Fake.DotNet.MSBuild/MSBuild.fs#L326-L419

I'm not sure if this is viable approach for NuGet. Honestly I'm not all to happy with the NuGet module API...

@matthid matthid added the waiting for author Some information or action was requested and it needs to be addressed. Or a response from author label Feb 14, 2019
@atlemann
Copy link
Contributor Author

I'm trying to figure out if anything can be shared. The NuGet.exe module combines pack and push in the same arguments. However, NuGet pack doesn't build the project like dotnet pack does, so if we want to do something similar for the DotNet.Cli module, we would also need the CliArguments.

@atlemann
Copy link
Contributor Author

The Process.withFramework also makes reuse of the NuGet publish hard, since the whole point is not to use Mono.

https:/fsharp/FAKE/blob/2ec240f1d954500dab852bb4aacb6bd1b49b4e1e/src/app/Fake.DotNet.NuGet/NuGet.fs#L344

@atlemann
Copy link
Contributor Author

But I guess we could split the pack and push specific parts of the current NuGetParams into seperate records and have some conversion between the current NuGetParams (like for msbuild) and a new one which holds the pack and push ones? Then they would reuse the same records at least.

@atlemann
Copy link
Contributor Author

Maybe we need to update DotNet.Cli.PackOptions to hold some that new pack specific record as well then. Like Authors, Tags, Description etc.

@matthid matthid removed the waiting for author Some information or action was requested and it needs to be addressed. Or a response from author label Feb 26, 2019
@atlemann atlemann changed the title 2148: Add dotnet nuget push command and arguments [WIP] 2148: Add dotnet nuget push command and arguments Feb 28, 2019
@atlemann
Copy link
Contributor Author

atlemann commented Mar 2, 2019

@matthid Not sure I'm going in the right direction here, but at least most of the code is shared between the two modules.

Another thing, the NuGet.publishSymbols function seems to call publish if it fails and not itself, is that a bug?

…ommon Options.

Rename options in NuGet module to NuGetPushParams.
Copy link
Member

@matthid matthid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I'm lacking a better approach, I think the one proposed in this PR is fine. I have added some detail comments which we need to address/answer

@@ -39,6 +39,18 @@ type NugetSymbolPackage =
/// Build a symbol package using the nuspec file
| Nuspec = 2

type ToolOptions =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add short docs for this or mark it internal/private?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll make it internal, since I'm not reusing it in the DotNet module anymore.

param.Timeout |> Option.map string |> Option.map (sprintf "-Timeout %s")
]
|> List.choose id
|> String.concat " "
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use the proper APIs for this (Arguments.ofList for example)?


module Private =
/// For internal use
let rec push (options : ToolOptions) (parameters : NuGetPushParams) (toCliArgs : NuGetPushParams -> string) nupkg =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this only currently handles dotnet nuget push we should think about other commands as well.

  • Do we add all operations by adding new functions one by one on demand?
  • Should we use a similar model as dotnet uses where you have a "low"-level DotNet.exec function where others like dotnet test build on top.
  • Something different?

Personally I'd lean to something along the second option, but if there are good reasons to do it differently I'm all ears. Note that I'm not proposing to implement all options in this PR, but whatever we decide to release should be extendible later.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The second option sounds like a good idea so I'll not reuse this in the DotNet module, but rather use the exec in there instead. I'll for now make this NuGet.Private.push internal instead and maybe it could be generalized to be the low level one?


try
let result =
let tracing = Process.shouldEnableProcessTracing()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we really want to disable tracing we should use the corresponding CreateProcess functionality. We should remove this class to Process.shouldEnableProcessTracing to reduce side effects.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I just copied some other code in the same module. I can just remove it I guess.

@matthid
Copy link
Member

matthid commented Mar 16, 2019

Sorry for the late reply.

But I guess we could split the pack and push specific parts of the current NuGetParams into seperate records and have some conversion between the current NuGetParams (like for msbuild) and a new one which holds the pack and push ones?

I think I have answered this in the comment regarding which API surface we want, we could try a similar approach as dotnet itself but we need good documentation as the syntax will become a bit messy (to edit nested record fields)

Another thing, the NuGet.publishSymbols function seems to call publish if it fails and not itself, is that a bug?

To be honest I don't know. I'm not really using this module myself :)

Make NuGet.Private.push private
Use DotNet.exec for DotNet.nugetPush instead of NuGet.Private.push.
@matthid matthid self-requested a review March 17, 2019 17:17
@matthid
Copy link
Member

matthid commented Mar 17, 2019

Changes look reasonable, is there anything left as this is still marked WIP?

@atlemann
Copy link
Contributor Author

Not really, I guess I was to tired to notice 😁

@atlemann
Copy link
Contributor Author

How do I edit the title from a phone...hmmm...

@atlemann atlemann changed the title [WIP] 2148: Add dotnet nuget push command and arguments 2148: Add dotnet nuget push command and arguments Mar 17, 2019
@atlemann
Copy link
Contributor Author

I kind of feel the NuGet module is obsolete now that there is dotnet CLI. But I guess it might be a bit drastic to deprecate it?

@matthid
Copy link
Member

matthid commented Mar 17, 2019

But I guess it might be a bit drastic to deprecate it?

Indeed, but we could do it eventually. Sorry, just one more request, can we add a simple test for this (ie similar to others a single test checking if command line generation is OK)?

matthid
matthid previously approved these changes Mar 17, 2019
@atlemann
Copy link
Contributor Author

Yes, I can add a test.

- Add nupkg to arguments
- Convert timeout TimeSpan to seconds
@atlemann
Copy link
Contributor Author

Added some tests and fixed some bugs. I also added retry like in the NuGet module.

Copy link
Member

@matthid matthid left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks again. One more minor nit (but I can do that myself once I'm ready to merge this in a couple of days, so don't worry):
I think we should add a bit of docs for NuGetPushOptions and a single example changing some parameters on top of the DotNet.nugetPush function (just like we have for the DotNet.msbuild function), because people might not realize how to change nested records in F#.

@matthid matthid merged commit c38a472 into fsprojects:release/next Apr 4, 2019
@matthid matthid mentioned this pull request Apr 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants