where do my python files go in linux?

[Jorgen Bodde]

Hi All,

I am trying to make a debian package. I am following the tutorial by
Horst Jens (http://showmedo.com/videos/video?name=linuxJensMakingDeb&fromSeriesID=37)
and it is very informative. However one thing my app has and his
doesn't, is multiple python files which need to be executed. For
example

{dir}/app
app.py

app.py calls a lot of modules in {dir}/app. Horst says the python file
goes in /usr/bin/app.py which is ok with me, but I have multiple
python files, and I decided to use an app.sh script to call my python
files. In the /usr/bin I do not see subdirs so I assume that is not
really desirable.

Question 1. Where do I put the bulk of python scripts in a normal
linux environment?
Question 2. Should I use *.pyc rather then *.py files to speed up
executing as the user cannot write to /usr/bin or any other dir in the
system and everytime my app runs it will recompile it

Thanks for any advice or maybe a good tutorial how to set up files in
a linux environment

With regards,
- Jorgen

 

[Carl Banks]

I am trying to make a debian package. I am following the tutorial by
Horst Jens
(http://showmedo.com/videos/video? name=linuxJensMakingDeb&fromSeriesID=37)
and it is very informative. However one thing my app has and his
doesn't, is multiple python files which need to be executed. For example

{dir}/app
app.py

app.py calls a lot of modules in {dir}/app. Horst says the python file
goes in /usr/bin/app.py which is ok with me, but I have multiple python
files, and I decided to use an app.sh script to call my python files. In
the /usr/bin I do not see subdirs so I assume that is not really
desirable.

Question 1. Where do I put the bulk of python scripts in a normal linux
environment?
Question 2. Should I use *.pyc rather then *.py files to speed up
executing as the user cannot write to /usr/bin or any other dir in the
system and everytime my app runs it will recompile it

Thanks for any advice or maybe a good tutorial how to set up files in a
linux environment

On a Debian system:


I would put app.py in /usr/local/bin. I would create the directory
/usr/local/lib/app, and put all other *.py and *.pyc files there. At the
top of app.py, I'd add the following line so that I could import files
directly from /usr/local/lib/app:

sys.path.insert(0,'/usr/local/lib/app')


Alternatively, using your app.sh approach, I'd put app.sh in
/usr/local/bin/, and all *.py and *.pyc files in /usr/local/lib/app. I'd
invoke Python something like this:

PYTHONPATH=/usr/local/lib/app:$PYTHONPATH python -m app

(The -m switch searches the Python path for a module to run.)


If it's more of a library than an application (maybe there is a command
line script, but users could want to import the modules directly), then
I'd stick all the modules in /usr/local/lib/python2.x/site-packages, and
the command line scripts in /usr/local/bin.


Yes, install the *.pyc files. I recommend putting *.py files there as
well, so users can refer to it if there are any problems, but you don't
have to. The Python module compileall is your friend here.


Carl Banks

 

[Florian Diesch]

I am trying to make a debian package. I am following the tutorial by
Horst Jens (http://showmedo.com/videos/video?name=linuxJensMakingDeb&fromSeriesID=37)
and it is very informative. However one thing my app has and his
doesn't, is multiple python files which need to be executed. For
example

{dir}/app
app.py

app.py calls a lot of modules in {dir}/app. Horst says the python file
goes in /usr/bin/app.py which is ok with me, but I have multiple
python files, and I decided to use an app.sh script to call my python
files. In the /usr/bin I do not see subdirs so I assume that is not
really desirable.

Question 1. Where do I put the bulk of python scripts in a normal
linux environment?
Question 2. Should I use *.pyc rather then *.py files to speed up
executing as the user cannot write to /usr/bin or any other dir in the
system and everytime my app runs it will recompile it

Thanks for any advice or maybe a good tutorial how to set up files in
a linux environment

Have look at the Debian Python Policy
(should be in /usr/share/doc/python/python-policy.* on
Debian systems)

With regards,
- Jorgen

Florian

 

[A.T.Hofkamp]

Question 1. Where do I put the bulk of python scripts in a normal
linux environment?
Question 2. Should I use *.pyc rather then *.py files to speed up
executing as the user cannot write to /usr/bin or any other dir in the
system and everytime my app runs it will recompile it

Thanks for any advice or maybe a good tutorial how to set up files in
a linux environment

Rather than re-inventing the wheel, please have a look at distutils:
http://docs.python.org/lib/module-distutils.html

It does most if not all of the things you want to do.
If you want something more advanced, read about eggs.


Sincerely,
Albert

 

[Paul Boddie]

Rather than re-inventing the wheel, please have a look at distutils:
http://docs.python.org/lib/module-distutils.html

It does most if not all of the things you want to do.
If you want something more advanced, read about eggs.

Although distutils does some of the work needed by the inquirer, it
falls far short of what is needed to make a Debian package - that's
why you have the "new" Debian Python policy and why the authors
specifically refer to both distutils and setuptools in that document.
Meanwhile, even stdeb [1] doesn't appear to completely automate the
production of Debian packages using distutils.

The Debian packages that I've attempted to make have, in fact, mostly
employed distutils to "install" the files into the package, and as the
policy document indicates, you have to turn off various setuptools
features to persuade that software to play along if you're using it.
However, there's a lot of other stuff that neither distutils nor
setuptools do adequately, and setuptools' lack of integration with the
non-Python universe doesn't exactly make it a great replacement for
the system package and dependency managers in most GNU/Linux
distributions.

I've been tempted at various points to use something like SCons (or
similar [2]) rather than work around undesirable behaviour in
distutils. And although some might say that setuptools is an
improvement on distutils, it's an improvement in a direction that
interests me very little.

Paul

[1] http://stdeb.python-hosting.com/
[2] http://wiki.python.org/moin/ConfigurationAndBuildTools

 

[Nick Craig-Wood]

Although distutils does some of the work needed by the inquirer, it
falls far short of what is needed to make a Debian package - that's
why you have the "new" Debian Python policy and why the authors
specifically refer to both distutils and setuptools in that document.

It would be nice to have an equivalent to dh-make-perl which takes a
CPAN module and makes a .deb directly.

http://packages.debian.org/stable/devel/dh-make-perl

What I usually do is

python setup.py bdist_rpm

Then use alien to convert the resulting .rpm into a .deb

I don't think these create particularly policy compliant .debs but
they are good enough for local usage.

Meanwhile, even stdeb [1] doesn't appear to completely automate the
production of Debian packages using distutils.

Looks interesting though!

[1] http://stdeb.python-hosting.com/

 

[Jorgen Bodde]

Hi All,

Sorry for the late reply back, I had a busy weekend ... it seems there
is no clear way to do it and maybe that is why I was / am so confused.

Eventually I searched for *.py files, and like I said most apps seem
to install in /usr/share/{app} I believe that location is for data
only that is shared between users. But for simplicity's sake I put my
whole python application in there. It saves me setting a lot of paths
differently.

I made a symbolic link in /usr/bin that points to /usr/share/{app}/{app}.py

This all seems to work fine. When I am getting more experienced with
Debian / Ubuntu and linux overall, I will re-evaluate this and see if
I can improve it.

Thanks all for your answer,
- Jorgen

Although distutils does some of the work needed by the inquirer, it
falls far short of what is needed to make a Debian package - that's
why you have the "new" Debian Python policy and why the authors
specifically refer to both distutils and setuptools in that document.

It would be nice to have an equivalent to dh-make-perl which takes a
CPAN module and makes a .deb directly.

http://packages.debian.org/stable/devel/dh-make-perl

What I usually do is

python setup.py bdist_rpm

Then use alien to convert the resulting .rpm into a .deb

I don't think these create particularly policy compliant .debs but
they are good enough for local usage.

Meanwhile, even stdeb [1] doesn't appear to completely automate the
production of Debian packages using distutils.

Looks interesting though!

[1] http://stdeb.python-hosting.com/