replies inline On Mon, Nov 12, 2018 at 4:59 PM Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) <[email protected]> wrote: > Is pyyaml part of the batteries-included packages? > If not, we’ll need a way to distribute pyyaml.whl as part of the traffic ops > RPM. (For those of us without permitted Internet access in our deployments, > installing via pip means standing up our own private PyPi repo) at each of > our customers- something I would really like to avoid. > > I don't believe it is part of the standard library, but I do believe > we can figure out a way to keep it all self-contained to the traffic > ops RPM without requiring internet access at install time. I think > https://github.com/pyinstaller/pyinstaller is more than capable of > doing that on Linux/Mac/Windows. I just tried it out on my Python > version of db/admin.pl on my mac, and it created a self-contained > binary of 4.7MB size that seems to work just fine. It does still > depend on the external commands like `psql` et al. from the postgres > package, but that's no different from the current Perl version. Do you > think that would be sufficient? > > I think pyinstaller also solves the python2 vs python3 availability > problem, since the interpreter is packaged into the resulting binary > itself. > EF> I think that would be OK. The licensing on that one is GPLv2 which is > category X to include in source (we can distribute the boot loader though). > Do you know of any alternatives with more compatible licensing?
It wouldn't need to be included in the source; it would just be used at build time. But there is also this information on its website (http://www.pyinstaller.org/license.html): > PyInstaller is distributed under the GPL license (see the file COPYING.txt in > the source code), with a special exception which allows to use PyInstaller to > build and distribute non-free programs (including commercial ones). In other > words, you have no restrictions in using PyInstaller as-is, but any kind of > modifications to it will have to comply with the GPL license. See also our > FAQ. According to https://www.apache.org/legal/resolved.html#prohibited we are ok to use a GPL'ed tool during the build but cannot include the GPL'ed source code in our distribution. There is also the question of actually including/distributing the python interpreter+standard library in our rpm (as part of the standalone binary produced by pyinstaller), but I believe that should be fine according to https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq#Can_I_bundle_Python_with_my_non-open-source_application.3F. Here is is the relevant quote: > Can I bundle Python with my non-open-source application? > Yes. Unlike some open source licenses, the PSF License allows Python to be > included in non-open applications, either in unmodified or modified form. That said, I'm starting to lean more towards Golang for replacing db/admin.pl, because we already use it heavily and it checks off a lot of the boxes. It might seem a bit like overkill for scripting stuff, but there is definitely growing usage of Go as a script-like executable (see https://github.com/codeskyblue/go-sh and https://github.com/erning/gorun) for things you'd normally just write in Bash or some other scripting language. There's just a lot more involved in using Python for this (pyinstaller, pipenv, 2 vs 3, etc) than Go. - Rawlin
