Open jchadwick-smug opened 4 years ago
Hey, I was just looking for such an option, so "Nice idea" IMHO !
In the meantime, I've just added :
import sys
sys.dont_write_bytecode = True
... to the setup.py
, and the resulting .DEB package does not contain any byte-code anymore :ok_hand: :100:
Source : https://stackoverflow.com/a/9562273.
Bye :wave:
EDIT 2020-03-28 : @jchadwick-smug a cleaner method to imitate the "regular" Setuptools behavior.
EDIT 2020-04-14 : Hmmm... It finally appears the environment variable is well propagated in my case, even without the workaround described above :thinking:
Thank you :)
On Thu, Mar 26, 2020 at 9:34 AM Samuel FORESTIER notifications@github.com wrote:
Hey, I was just looking for such an option, so "Nice idea" IMHO !
In the meantime, I've just added :
import sys
sys.dont_write_bytecode = True
... to the setup.py, and the resulting .DEB package does not contain any byte-code anymore 👌 💯
Source : https://stackoverflow.com/a/9562273.
Bye 👋
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jordansissel/fpm/issues/1690#issuecomment-604534037, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAF2QZI24VRV6DJALCF6TRJN7ZXANCNFSM4LT4V5VQ .
Setting PYTHONDONTWRITEBYTECODE=1
(PYTHONDONTWRITEBYTECODE=1 fpm ...
) works for me too. I can't think of a reason to ever want such files in a Debian package. Should fpm invoke Python with -B
by default?
At my workplace we often build Python packages using
fpm -s python -t deb
.However, this has the negative side effect of the spawned
setup.py
and subsequent bits generating.pyc
files and__pycache__
directories, which are not supposed to be part of Debian/Ubuntu packages. There are several reasons for this which are irrelevant to this discussion, but here's some historic evidence:(This is in direct conflict with #468 where the requester actually desired pyc/pycache bits. Just goes to show everyone's use-cases are different; we try to comply with Debian/Ubuntu distro packaging norms.)
There are 2 clean ways in Python to cease this behaviour. This applies to both Python 2 and Python 3 (even extremely old versions), but we use Python 3 in the below example:
PYTHONDONTWRITEBYTECODE
environment variable in some manner (ex.export PYTHONDONTWRITEBYTECODE=1
, orPYTHONDONTWRITEBYTECODE=1 python3 setup.py ...
), or,-B
flagI couldn't get fpm to let me do either. Reasons:
execl()
directly for/usr/bin/python3
rather thansystem()
. Shell env vars,/etc/environment
, etc. all have no bearing,--python-bin '/usr/bin/python3 -B'
to try and force the-B
flag into the argument list (the argument itself is a literal string)The current model fpm uses for launching
setup.py
is perfectly sound and reasonable (usingsystem()
opens up a very ugly can of worms); we don't want to see that part changed. But...We'd benefit greatly from a flag, like
--python-no-bytecode
(call it whatever you want), which would either:execle()
to include thePYTHONDONTWRITEBYTECODE
environment variable, or,python3
(or--python-bin
) with the-B
flag when runningsetup.py
. (I suspect this option is safer and very easy to implement)This would save us from having to "do everything by hand", ending up using
fpm -s dir -t deb
instead.Thank you!