On Sat, Sep 2, 2017 at 4:55 AM, Robert Alegrid <eraleg...@hotmail.com> wrote: > I apologize in advance if I formatted this message incorrectly or addressed it > incorrectly. This is the first time I'm posting to a mailing list, so I have > no > real idea how I should be doing it. > > I also just program as a hobby (and mostly on Windows at that), so that should > be taken in consideration as well. > > On Saturday, 2 September 2017 7:03 PM, Romain Tartière wrote: >>On Fri, Aug 25, 2017 at 09:41:43PM +0200, David Naylor wrote: >>> [2] A general discussion needs to be had around nuget packages. How do we >>> consume them? >>> i) as downloads with each port containing a copy >>> ii) local ports with consistency across the Ports Collections >>> iii) A mixture of the above (i.e. (ii) is there is a native component, >>> otherwise (i)) >>> I prefer (ii) as I think it gives the end user the best leverage to patch >>> issues with nuget packages locally (and to get updates without waiting on a) >>> upstream, and b) us/ports maintainer). However, at this point that option >>> is >>> at 0% progress. > It's possible for NuGet to use a local directory as a feed: > https://docs.microsoft.com/en-us/nuget/hosting-packages/local-feeds > If you add the local feed earlier in the list of sources, it should pick up > your > locally built packages instead of fetching it from the internet. > > NuGet also maintains a cache of packages that it uses to restore from when it > doesn't have an internet connection to work with. > >>Yeah, it's a problem that is broader and broader… and for which I don't >>think a universal solution works :-/ >> >>With local copies (i) you end-up with a lot of duplication (Go >>applications are a good example of how this can become quite stupid, I >>recently created a port for a go application, the source tarball >>includes the source of all dependencies, and everything is bundled in a >>13MB executable (that only depends on libc.so and libthr.so). >> >>With a port per dependency (ii), you sooner or later have to handle >>conflicts between dependencies (port A needs foo-1.0.0 but port B needs >>foo-2.0.0) and it can get tricky. > When building a prgram, you can save > You're going to end up with a lot of duplication either way, given how > assembly > locations are resolved: > http://www.mono-project.com/docs/advanced/assemblies-and-the-gac/ > >>I only have experience with programming with Ruby as a language that has >>similar problem. I ended at only installing system tools using the >>FreeBSD ports (e.g. puppet, vagrant, passenger), and for applications I >>actually use, I just grab the source, and use bundler to gather all >>dependencies as the user running the software, therefore I end up having >>something similar to (i) without using the port system. >> >>My weak Windows development experience learned me to put all dll of an >>application in the application directory. If it's still a good advice, >>I guess that each application should have it's copy of all it's >>dependencies, and therefore each port should install a bundle of all >>what is required by it. > Aside from a few special assemblies which live in the GAC, yes, that's > basically > what you're supposed to do. > >>Another problem with nugets packages is that you only get binaries, >>right? That means that is something goes really wrong, there is no way >>to audit the source code of what led to disaster. The problem is >>similar with the few Java projects I gave a look at. My feeling is that >>this is even worst :-( Ruby being interpreted, there is no such >>problems. > NuGet packages have in their manifest a field to specify where the source code > lives. However, since it's optional and is just a URL to the repository, it > probably doesn't help much for this use case.
Is this coming up because of the use of Nuget during the build process or is it because of general concern for the user? As a professional DotNet developer, I agree with Mr. Alegrid for the most part. Nuget is designed as a binary tool because DotNet is a binary based system. It comes from a user mindset, not an opensource mindset. Because of that, I question why we are having this discussion. Is it not the decision of the user/developer how they would like to use their package manager? Also, it is their choice if they prefer to use sources. I sometimes do both. Stable packages from Nuget and others from source. Nuget is designed for local, per project resources. It is particularly effective when developing across many developers as it will go and get the packages for you automatically at build time (wicked cool feature, which seamlessly mixes source with binary distribution). Items that are supposed to live system wide are to be stored in the General Assembly Cache (GAC) and should be designed to be put there. You can get Nuget to drop things in the GAC but have not used this feature. The GAC is designed around large scale software deployments which, sadly, I don't think will ever apply to mono on FreeBSD. Worrying about per-port repositories for Nuget is not a thing because the manifest within DotNet applications decides what runtime version of the assembly to use at build time so it is necessarily per-port. Also, DotNet can have hard or soft links (I forget the terminology) to required assemblies in the sense they can specify to use any version or a specific version, and can specify if the assemblies require to be signed (i.e. verified by the authors credentials against a trusted list). The GAC handles versioning for system level assemblies and if you overwrite a required version in your local repository it's a development error that you need to sort yourself. I had another point but I forgot it so I may speak up again later if anyone finds the above relevant to the discussion. Cheers, Russ _______________________________________________ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
