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
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
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org