I'm replying to Jan's message inline because I think it raised important points I want to reinforce with my voice. On 02/17/2017 08:00 AM, jan matejek wrote: ...
2. dropping .pyc and compiling on installation That's certainly possible (Debian does something of the sort) and has even some interesting advantages: it allows you to transparently support many different python versions simultaneously with just one package install. Of course, it would be a lot of work. Doing this manually in every package is not realistic, we'd need some sort of automation that does this for a package in a single macro, or maybe a "python-central" tool that you run against the filelist in %post, or something... You would also have to %ghost all the .pyc files, otherwise all you get is a big ugly mess of not-owned files. The singlespec macro set could help with this, possibly even creating the %post/%preun scriptlets and %ghost entries automatically in packages.
This requires further discussion on the tradeoffs, probably at least a rudimentary install time benchmark, but I'm not opposed to including something like this.
I guess this could make sense to some subset of users/packages/use cases etc., but it seems like an awful lot of work to solve a problem that I am not sure is even there.
3. dropping .pyc without replacement That could be reasonable in some packages, if we know that they are long-running and the startup time difference is negligible to users... which is up to the individual maintainer, i suppose. It's probably a bad idea for libraries, which tend to be used by command-line tools, where startup time matters.
If I understand what you are saying this is a non-starter for me. Python will produce the .pyc files when the .py files get run, unless the user were to always supply a flag on the Python command line, which is not even a possibility when using many Python command line tools. So if only .py files are distributed, then there will be a lot of .pyc cruft left on the system after a package is uninstalled.
4. reproducible builds For now, where it matters, let's touch generated .py files with a set time (probably mtime of tarball?). I suspect this is not an issue in most packages, so automation doesn't really help? But I'd be happy to learn more, e.g. see packages that don't build reproducibly and check out why that happens.
This seems a reasonable strategy to help solve the original question.
5. dropping .py That's a big NO. First of all, it's simply not worth it. On my work machine, which has a higher-than-usual amount of pythonic packages, the grand total size of all "*.py" files is 208 MB. Out of a 7.6GB /usr. Salt itself, which I installed for the purpose of this experiment, is 17 MB of that.
This I whole-heartedly agree. Cannot drop the .py files. Python software *is* the .py files. Python is an interpreted language and the fact that the .pyc concept exists doesn't change that. Also, does any other distro do this? There should be a good reason behind doing something no one else is doing. ...
(also, if 15 MB matter to you, maybe don't base your software on a language with a 50MB stdlib of which you need maybe a third, if that... or on a language where the sizes of source code and compiled objects are comparable ;) )
This is the key point IMO. I don't think a distribution should be trying to "solve" the "problems" it sees in a particular programming language. When a developer chooses a language they are also choosing its particular strengths and limitations, whether the developer understands that or not. If a particular user/use case can't abide with something on the magnitude of tens to hundreds of MB (this population has to be the tiniest sliver of the distro's potential user base), then they should look at alternative software. It shouldn't be the job of a general purpose Linux distribution to "solve" the tradeoffs implicit in the developer's choices when the vast majority of users don't need such a "solution". -- Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org