[ninux-dev] Python-Django bundled libraries

[Nemesis]

On 12/12/2016 01:31 PM, Germano Massullo wrote:
> Il 12/12/2016 10:21, Nemesis ha scritto:
>> On 12/03/2016 11:36 PM, Germano Massullo wrote:
>>> Il 28/11/2016 15:37, Nemesis ha scritto:
>>>> Non ho detto d3, ho detto "librerie javascript opensource".
>>>>
>>>> Ad esempio:
>>>> https://github.com/django/django/tree/master/django/contrib/admin/static/admin/js/vendor
>>> Ok grazie. Ho appena aperto il bugreport
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1401243
>> Gli puoi chiedere in modo esplicito se è possibile adottare una
>> soluzione simile perchè più comoda per le applicazioni e i framework web?
>>
>> Federico
>>
> Te lo dico io direttamente. Si può fare, fino a quasi un anno fa dovevi
> fare tutta una procedura burocratica, ora invece le regole affermano che
> sebbene tu debba evitare di immettere pacchetti che includano anche
> librerie, se proprio sei costretto allora devi dichiararli nel file
> spec. Personalmente sono fermamente contrario ad inserire pacchetti che
> contengano librerie al proprio interno[1], quelle uniche due volte che
> l'ho dovuto fare ho prima tentato in tutti i modi di venirne a capo.
> Inoltre si trattava di roba che non poteva esser raggiunta da internet,
> quindi nel caso di python-django-netjsongraph, a mio avviso, che non ho
> molta esperienza in sviluppo web, la questione si complica. Se non si
> riesce a venirne a capo in maniera semplice, penso sia meglio lasciar
> cadere la cosa e dedicarsi alla pacchettizzazione degli altri software
> sviluppati da OpenWISP.

Negli altri progetti (web) OpenWISP avremo lo stesso problema, in
particolare django-netjsonconfig.

Credo che la cosa più semplice sia includere la libreria così com'è ora,
ma solo per le applicazioni web. Alla fine è un file JS che deve essere
letto da un browser, quindi da molti meno problemi di sicurezza rispetto
a una cosa come una libreria C.

> Vit Ondruch è uno dei membri del Fedora Ruby Special Interest Group
> (SIG), cui ho chiesto suggerimenti vari su queste situazioni. Per
> completezza informativa condivido il seguente di e-mail, del quale ho
> avuto l'autorizzazione per la pubblicazione.
> 
> [1]: motivazioni
> https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries
> 
> ================================================================
> 
> Germano:
> [...] This time I need to ask you a thing about collaboration between
> upstream
> and packagers.
> I started a discussion [1] in Fedora devel mailing list but I was not
> satisfied about it. In short: a my friend is the developer of
> django-netjsongraph[2] and since that web application bundles
> javascript-d3, he asked me what he could do in future to make packager
> life easier (so not bundling libraries, etc.).
> Do you think that using git tools submodules [3] could be a good way to
> make easier the work of both upstream developers and distro packagers? I
> mean, if upstream needs to get a full working release, git submodules
> could insert libraries on the fly, on the other hand, on Fedora we could
> just leave empty such external git repo referencies and fill them with
> the already packaged libraries... Is that correct?
> 
> Thank you and have a nice day
> 
> [1]:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2Q6DLLRQF2CDJEW2EM5WSRGE2C3ZUNBZ/
> [2]: https://github.com/interop-dev/django-netjsongraph
> [3]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
> 
> ================================================================
> ================================================================
> 
> Vit:
> So if I get your proposal right, you have App Y, which bundles library
> X, e.g. there is Y/X directory. And when you are packaging, you propose
> to package library X, so it lives for example in /usr/lib/X, then
> package App Y into /usr/lib/Y, but remove the original directory
> /usr/lib/Y/X and replace it by symlink to /usr/lib/X. Right? Yes, that
> is one possible way. And we do this. And it is relatively ok for
> interpreted languages. rubygem-jquery-rails [1] might be one example.
> 
> But if you check the jquery-rails more carefully, you'll see that
> currently not all the libraries are unbundled and the reason for that
> is, that upstream is too picky about version and that might be the
> problem. Typically, once upstream does something like this, they build
> everything around the specific version and are reluctant to make the
> code more universal to support more versions. And as you know Fedora, it
> is not easy to have multiple (or every) versions of library in distribution.
> 
> The other case is, when upstream bundles some C library for example. In
> this case, they tend to statically link everything and that is a mess.
> If there applies "don't bundle" for the previous case, it applies twice
> as much for compiled code.
> 
> And there are cases like rubygem-therubyracer. It used to bundle v8,
> which was relatively easy to unbundle (and you really don't want to
> maintain v8, believe me). But the upstream unfortunately
> moved v8 into its own libv8 gem. At that moment, there was virtually no
> way how to unbundle the v8, since they give the v8 gem even the same
> version as the version of bundled v8. In that case, we would have
> rubygem-libv8-5.3.332.38.3 but if it wanted to use the system
> v8-1:5.2.258-7.fc26.x86_64 you see it is of different version. This is
> not maintainable at all.
> 
> In your specific case, I'd be surprised if javascript-d3 does not bundle
> anything else. These JS libraries typically looks as just one file, but
> in reality, they are composed from multiple libraries and it is hard to
> untangle this mess. You might take a look at rubygem-uglifier ...
> 
> These are my thought on bundling. Not sure I gave you any answer, but I
> hope it give you some glimpse ...
> 
> [1]:
> https://src.fedoraproject.org/cgit/rpms/rubygem-jquery-rails.git/tree/rubygem-jquery-rails.spec#n87
> 
> ================================================================
> ================================================================
> 
> Germano:
> Thank you Vit, you showed me some very interesting scenarios. In my case
> the upstream is 100% available to listen to our suggestions. What would
> you suggest him to do? Perhaps the way I mentioned before (the git
> submodules) is not the best choice.
> Thank you very much!
> 
> ================================================================
> ================================================================
> 
> Vit:
> I also forgot to mention licensing. It happens many times, that the
> .gemspec specifies some license, but it does not reference any license
> of bundled libraries.
> 
> So I'd say that if there is no other options, then it'd be nice to have
> "vendor" directory in the project root directory, to make it obvious
> that something is bundled and git submodules in this directory should be
> fine.
> 
> At the end, if the upstream is releasing source tarballs, it will be
> just regular directory and nobody can tell the difference if it was
> submodule or if the library was just copied there. It'd be nice to use
> some stable releases not just random git hashes and it be nice if
> upstream is open to support multiple versions of the library, i.e.
> respect some API versions.
> 
> ================================================================
> ================================================================
> 
> 
> _______________________________________________
> ninux-dev mailing list
> ninux-dev at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/ninux-dev
>