By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,345 Members | 1,775 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,345 IT Pros & Developers. It's quick & easy.

another distutils question

P: n/a
is there anyway I can, in a setup.py file, set and internal equivalent
to the '--install-scripts' commandline option?

script installation directory but I don't want on the command line where
things can go horribly wrong if the user forgets. I would like to
create a new default setting for this commandline option as well as a
couple of other such as the data default directory.

--- eric

Sep 29 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
On Fri, 29 Sep 2006 13:53:46 -0400, Eric S. Johansson wrote:
is there anyway I can, in a setup.py file, set and internal equivalent
to the '--install-scripts' commandline option?

script installation directory but I don't want on the command line where
things can go horribly wrong if the user forgets. I would like to
create a new default setting for this commandline option as well as a
couple of other such as the data default directory.

--- eric
On a similar note , I have another question about distutils and data files.
I have a little program that uses a txt file to store data, and it works
fine running it in it's own folder, if I install through distutils, using
sudo to get it to write to the site-packages folder (which root owns), it
installs the data file so that it is owned by root, and not by me, so
that the data file can't be written to (although the script can read it).
Do I need to run a post install script, or add something to setup.py file
to chown the file or am I doing something wrong? There doesn't seem to be
anything on this in the docs.
Thanks in advance,
Keith

Sep 29 '06 #2

P: n/a
Keith Perkins wrote:
On a similar note , I have another question about distutils and data files.
I have a little program that uses a txt file to store data, and it works
fine running it in it's own folder, if I install through distutils, using
sudo to get it to write to the site-packages folder (which root owns), it
installs the data file so that it is owned by root, and not by me, so
that the data file can't be written to (although the script can read it).
Do I need to run a post install script, or add something to setup.py file
to chown the file or am I doing something wrong? There doesn't seem to be
anything on this in the docs.
There's nothing in distutils specifically that will let you do this. The root
user will have to chown/chgrp/chmod/chwhatever the package that you installed
manually.

You shouldn't use package data for things that are going to be modified.
Instead, use a directory like ~/.myscript/ or something else.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

Sep 29 '06 #3

P: n/a
On Fri, 29 Sep 2006 18:57:12 -0500, Robert Kern wrote:
Keith Perkins wrote:
>On a similar note , I have another question about distutils and data files.
I have a little program that uses a txt file to store data, and it works
fine running it in it's own folder, if I install through distutils, using
sudo to get it to write to the site-packages folder (which root owns), it
installs the data file so that it is owned by root, and not by me, so
that the data file can't be written to (although the script can read it).
Do I need to run a post install script, or add something to setup.py file
to chown the file or am I doing something wrong? There doesn't seem to be
anything on this in the docs.

There's nothing in distutils specifically that will let you do this. The root
user will have to chown/chgrp/chmod/chwhatever the package that you installed
manually.

You shouldn't use package data for things that are going to be modified.
Instead, use a directory like ~/.myscript/ or something else.
I did install it in ~/.script/data.txt, and distutils set the
user/group as root. Is it impossible to install this with distutils?
Since I'm running setup as root, should I just add a class or method to
chown the datafolder/file to the installer. Should I use autotools
instead? I haven't looked into eggs yet would that be a better choice? The
data file is something that is necessary for the program (it reads it and
prints out a random line--the whole idea of the script)if that's all I
wanted it to do I wouldn't have any problems--I could even include it as a
list in the script file, but I would like the user to be able to add other
data.
Thanks,
Keith
Sep 30 '06 #4

P: n/a
Keith Perkins wrote:
I did install it in ~/.script/data.txt, and distutils set the
user/group as root. Is it impossible to install this with distutils?
Since I'm running setup as root, should I just add a class or method to
chown the datafolder/file to the installer. Should I use autotools
instead? I haven't looked into eggs yet would that be a better choice? The
data file is something that is necessary for the program (it reads it and
prints out a random line--the whole idea of the script)if that's all I
wanted it to do I wouldn't have any problems--I could even include it as a
list in the script file, but I would like the user to be able to add other
data.
Don't use "setup.py install" to install that directory. Imagine a case where the
root user installs the package for everyone on the system to use. How do the
multiple users get ~/.script/?

Instead, include the default data inside the package (read-only to non-root
users). Then allow the script itself to create the directory the first time it
is run (read-write, and it should then automatically be accessible to the user
that ran the script). You might also add a command-line option to *only* install
that directory.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

Sep 30 '06 #5

P: n/a
Keith Perkins wrote:
>
On a similar note , I have another question about distutils and data files.
I have a little program that uses a txt file to store data, and it works
fine running it in it's own folder, if I install through distutils, using
sudo to get it to write to the site-packages folder (which root owns), it
installs the data file so that it is owned by root, and not by me, so
that the data file can't be written to (although the script can read it).
Do I need to run a post install script, or add something to setup.py file
to chown the file or am I doing something wrong? There doesn't seem to be
anything on this in the docs.
1: as pointed out, site-packages is for code only :-)

2: you will need a post processing script.

here is an example of distutils abuse that may help a little bit. I
needed to collect files from a file hierarchy and one other place in the
source directory then stuff them in the right place in the production
directory. Since the pattern was unpredictable, I built a method to
accumulate data file references.

the solution is a bit more hard coded than I like but it gets the job
done for now. as I need to improve it, I'll fix it.

def expand_hierarchy(starting_point, data_files):
dir_files = os.walk(starting_point)

for (path, name, files) in dir_files:
x = os.path.basename(path)
if x != 'CVS':
clean_files = [ os.path.join(path,item) \
for item in files \
if (clean_test(item)) ]
data_files.append((cr_paths%path,clean_files))

return data_files

setup(...
data_files=expand_hierarchy("web-ui",
[(cr_paths%'etc',

['ancillary/baseline_configuration']),
],
)
to solve the file perms problem you run something after setup. how you
associate perms/ownership with a file is up to you. It might work to
use data_files to enumerate files you apply the common perms/owernship.
then special case what you need to.

hope this gives you some useful ideas.

--- eric

Sep 30 '06 #6

P: n/a
Robert Kern wrote:
Instead, include the default data inside the package (read-only to non-root
users). Then allow the script itself to create the directory the first time it
is run (read-write, and it should then automatically be accessible to the user
that ran the script). You might also add a command-line option to *only* install
that directory.
I would be okay with a package/data/... arrangement if and only if the
data within that directory was read only and only changed when the
package changed it. System specific changes would be in a system copy
of the configuration file and user specific changes would be a user copy.

If you create a configuration system which uses a union of all three
configuration files, you eliminate unnecessary replication of
configuration values, minimize changes necessary when the baseline
configuration file changes, and you also have the opportunity to
control scope of configuration variables. I.e. some that are only
changed in the system config file.

I have an application dependent version of this I've been using for the
past three years and, it's really nice. It lets me mostly ignore the
configuration files and focus on what I'm trying to solve.

--- eric

Sep 30 '06 #7

P: n/a
Thanks everyone, for your answers. They've been very helpful.
Keith
Sep 30 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.