Date: Sat, 2 Sep 2017 11:55:15 +0000 From: Robert Alegrid <eralegrid@hotmail.com> To: =?Windows-1252?Q?Romain_Tarti=E8re?= <romain@FreeBSD.org>, "freebsd-mono@freebsd.org" <freebsd-mono@freebsd.org> Subject: Re: Update on porting mono 5 Message-ID: <RO1P15201MB218761CDE84B83E1DF349DB8A8930@RO1P15201MB2187.LAMP152.PROD.OUTLOOK.COM> In-Reply-To: <20170902090359.GA47675@blogreen.org> References: <17078253.u2dgjZK1Z6@dragon.local> <20170815102120.GA29251@blogreen.org> <3186981.TyGdqNibkJ@dragon.local>,<20170902090359.GA47675@blogreen.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 hav= e no real idea how I should be doing it. I also just program as a hobby (and mostly on Windows at that), so that sho= uld be taken in consideration as well. On Saturday, 2 September 2017 7:03 PM, Romain Tarti=E8re 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.=A0 How d= o we=20 >> consume them? >>=A0=A0 i) as downloads with each port containing a copy >>=A0 ii) local ports with consistency across the Ports Collections >> iii) A mixture of the above (i.e. (ii) is there is a native component,=20 >> otherwise (i)) >> I prefer (ii) as I think it gives the end user the best leverage to patc= h=20 >> issues with nuget packages locally (and to get updates without waiting o= n a)=20 >> upstream, and b) us/ports maintainer).=A0 However, at this point that op= tion is=20 >> at 0% progress.=A0=20 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=85=A0 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=20 You're going to end up with a lot of duplication either way, given how asse= mbly 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.=A0 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.=A0 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 basi= cally what you're supposed to do. >Another problem with nugets packages is that you only get binaries, >right?=A0 That means that is something goes really wrong, there is no way >to audit the source code of what led to disaster.=A0 The problem is >similar with the few Java projects I gave a look at.=A0 My feeling is that >this is even worst :-(=A0 Ruby being interpreted, there is no such >problems. NuGet packages have in their manifest a field to specify where the source c= ode lives. However, since it's optional and is just a URL to the repository, it probably doesn't help much for this use case. Regards, Robert Alegrid=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?RO1P15201MB218761CDE84B83E1DF349DB8A8930>