You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 29, 2022. It is now read-only.
I wanted to report a small problem and suggest a possible solution.
The problem is that when the .py files are distributed into the filesystem from a package (f.e. under /usr/lib/enjarify or /usr/share/enjarify) by just copying them over, then no python caching files are created. One problem arises if anyone executes enjarify as root (yes that shouldn't be the case but why not) then python will create those cache object files for all python modules that are imported somewhere within your module. If anyone uninstalls your package afterwards, then the filesystem is left in a cluttered state as the generated object files are not tracked and remain.
Additionally there may also be a small performance improvement if python cache object files are distributed.
One possible solution would be to use python setuptools and create a setup.py that will distribute your python module files into f.e. /usr/lib/python3.5/site-packages/enjarify, which will also take care to create the cache entries if the -O1 parameter is passed when calling the setup.py.
You could still have your enjarify.sh script that checks for all your favorite python interpreters.
What do you think about this idea? If you need feedback or something like that, feel free... i try to help where i can 😄
The text was updated successfully, but these errors were encountered:
I haven't tried creating a package using setup.py before. I'll have to look into that some time. The problem of course is that I run it from a git repo in my home directory, so that's what the directions assume.
anthraxx
changed the title
improvement: python object cache filesystem cluttering (consider using setuptools setup.py for distributing .py files)
missing convenient python object cache generation/distribution (+ possible filesystem cluttering on uninstall)
Jan 5, 2016
@Storyyeller you are speaking about the enjarify.sh and its directory discovery, right? This shouldn't be a problem at all, this could still work as is.
The only main difference would be that there is a setup.py that could be used if someone wants to install it into the system or package your software. In such case the /usr/lib/python3.5/site-packages/ is the target location (but you can of cause still run it normally from your home or whatever directory).
You can also tell setuptools setup.py to distribute non .py files (like the enjarify.sh) so you would have a base dir /usr/lib/python3.5/site-packages/enjarify where the enjarify.sh is inside and also the enjarify directory with the python modules (so its .../enjarify/enjarify) therefor everything behaves as currently.
This way i could call something like
python setup.py install -O1 --root="${pkgdir}"
and it would create the cache files and distribute everything system-wide (so i just have to create the /usr/bin/enjarify symlink).
# for freeto subscribe to this conversation on GitHub.
Already have an account?
#.
Hey 😄
I wanted to report a small problem and suggest a possible solution.
The problem is that when the .py files are distributed into the filesystem from a package (f.e. under /usr/lib/enjarify or /usr/share/enjarify) by just copying them over, then no python caching files are created. One problem arises if anyone executes enjarify as root (yes that shouldn't be the case but why not) then python will create those cache object files for all python modules that are imported somewhere within your module. If anyone uninstalls your package afterwards, then the filesystem is left in a cluttered state as the generated object files are not tracked and remain.
Additionally there may also be a small performance improvement if python cache object files are distributed.
One possible solution would be to use python setuptools and create a setup.py that will distribute your python module files into f.e. /usr/lib/python3.5/site-packages/enjarify, which will also take care to create the cache entries if the -O1 parameter is passed when calling the setup.py.
You could still have your enjarify.sh script that checks for all your favorite python interpreters.
What do you think about this idea? If you need feedback or something like that, feel free... i try to help where i can 😄
The text was updated successfully, but these errors were encountered: