Create nuget package (without native libs) #744
Conversation
|
thx for this PR. RoadmapReleaseOn the longterm I would like to provide a nuget package with native libs for all supported platforms (like we do for python package). But this is more a requirement for doing a release from my side...
UserFor customer we should also provide the possibility to create/generate a package from its build directory only containing its platform kind of local custom package build. so maybe we'll need two .nuspec file one for user i.e. single platform package and one for multi-platforms release package Open to any feedback !!!! MiscIt seems there is also dotnet pack which only use the csproj and not the nuspec to create the package. DocumentationHere my wish list of RIDs (Runtime IDentifier) target |
Mizux
added
Feature Request
|
@Mizux For the native libraries, I think it would be cleaner to have a separate installer (with the destination being the system folders). This way, the |
|
if I understand you we should have several nuget packages:
note: let's call it frontend.
note: let's call them backends.
note: let's call it examples. Question: since we pass the name of the native library when generating cs wrapper (e.g. here) does it means that wrappers should also belong to each native packages ? I think to do it in several steps:
|
|
@Mizux I like the proposal with a few modifications. Yes, the native libraries and wrappers would need to be packaged together which reduces the platform build to a small wrapper module that only has the dotnet/C++ binding. That module would then be referenced from the remaining dotnet library without any knowledge of the underlying binding module. *nix: MacOS: Windows: Each of the above would be a separate package that would be installed in the GAC (to avoid location issues). Afterward the nuget package would be the top level libraries that only search for Google.OrTools.dll I would personally like to avoid platform information in nuget and essentially avoid the branching in some top level library. As we are tageting netstandardXX, net70 would come from whether the next version of the metaframework targets it (for instance if netstandard21 includes it we get it for free by upgrading the metaframework). As for examples, have a separate github project that people can checkout with a small subset of the examples used for development. I don't think a separate package is needed. |
|
@acco32 @Mizux Would you consider separating the examples into a separate |
|
The proposal above seems to match the standard convention for packaging native apps.
Some notes:
|
|
@jonwagner Good point re: GAC. I wasn't aware OR-tools was deploying there? Perhaps I missed something? Anyway, that should be something left to the applications guy(s), per se, minimum integrating OR-tools, if at all. But then again, with the advent of |
|
OR-tools isn't currently in the GAC, but it was a suggested solution above. |
|
@jonwagner do you know a public working example of this architecture ? note: I'm testing on pet project there https://github.com/Mizux/dotnet but still have some difficulties... |
|
@Mizux here's an article on how to do multi-runtimes as a single package: https://natemcmaster.com/blog/2016/05/19/nuget3-rid-graph/ The downside is that you get a large package with multiple sets of binaries, but it's really easy to do as a single package. I'm pretty sure that the large system-level packages split them somehow. Let me poke around and see if I can find an example. |
|
@Mizux I spent the last half hour looking for documentation and examples for packaging native libraries. They all seem to use the single-package approach. You build one package with files in a structure like this: The link I posted above has pretty good instructions. It will make a large package, but then consumers of the package will always have the files it needs. Now that I've looked at it I'd recommend going with the single-package approach. |
|
@jonwagner thanks for the link unfortunately in our case we must use the several-packages Fortunately after few weeks of effort I manage to do it cf my dev branch... ToDo before pushing:
|
|
@Mizux Blazing the trail. I like it; looking forward to seeing the path you forge. |
|
The |
|
@Mizux the dev branch looks good. |
|
Here a preview if you want to test on Windows only: i.e. |
|
@Mizux To be clear, I think we got our wires cross. When I think of Google.OrTools building for |
|
@mwpowellhtx As I said before I can't build one big package for the three OS targeted (win, linux, osx) on one machine so I create a "backend" package for each OS let's call them runtime packages. And one meta package the "frontend" depending on each of them and containing the
Please take a look at https://github.com/google/or-tools/tree/master/ortools/dotnet (feedback/PR welcome) |
|
@acco32 Since |
|
@Mizux I'm not sure what your sentence means means, "cannot compile any file in it, thus..." ? As far as I know, to OrTools build process, FSharp has always been a separate thing over and above and depending upon OrTools. You've got your dependencies mixed up. Open the packages as ZIP files; you don't even have to rename the extension. You will find FSharp depending on the now empty package Google.OrTools, which now depends on the zero value added "run time". Maybe I am oversimplifying, however, I'd suggest if this is the case that it is time to reconsider how OrTools builds. Given the cross platform nature of netstandard, it is easy to include the necessary binaries in the lib or even native directories, as far as I know. Case in point, let's say someone does want to run OrTools in .NET across platforms? Or even embedded? Then what? Hopefully on the other side of the Core/Standard dust settling things will be smoother, but for now, the effort is what it is. But having an entirely separate "runtime" package adds no value IMO but to confuse matters. I don't know about Mono, as I haven't followed it that closely. However, now that things are on the Core/Standard track, I don't see anything gained by dwelling there apart from a historical learning perspective. Thoughts? |
|
|
I'm closing this pull request since mizux/dev has been integrated to master... |
|
@Mizux In the context of NuGet packages, right? Come on, for Christ's sake, don't insult my intelligence here. You can open those, extract them, etc, like you would any ZIP file. From there look at the dependencies for yourself in the actual nuspec that got packaged. You can see clearly what the dependencies are. Re: the Core packages: Ah, I see, good point! 👍 Sorry if I came off a bit raw there. This whole netstandard thing is a mess and I'm trying to sort some things out by it myself. I do not think my experience therein thus far is too far from being on par with the rest of the industry to date. Once it is settled and behind us it will be much smoother I'm sure. Thanks for clarifying. |
|
One other thing I noticed. Can't wait to see the package finally published to NuGet. Approaching that, remember |
Change runtime.{rid}.Google.OrTools -> Google.OrTools.runtime.{rid}
note: nuget support team didn't want to give us runtime.{rid}.Google* reserved prefix
beside the fact they use this naming convention in the dotnetframework and give it to
"quamotion" company too
@Mizux I am unsure how you plan to package the native libraries for each operating system. This target will create the package for dotnet only. Once the native library installation is decided we can add it as a dependency to this package.