Hi,
I use the GNU Autotools when I program in C. They generate a config.h file containing useful information such as the PACKAGE_VERSION that can be retrieved by simply including the file. I'd like to know if there exists anything similar with distutils. I am trying to distribute a script where I should be able to output the current version number.
I thought that I could do things in an opposite way as in C. Rather than having the building system to create the config.h, I could import a config.py in my setup.py and distribute it as a py_module along with the script.
Do you have better solutions?
At 12:26 AM 6/16/2010 +0200, Denis Jasselette wrote:
I am trying to distribute a script where I should be able to output the current version number.
I thought that I could do things in an opposite way as in C. Rather than having the building system to create the config.h, I could import a config.py in my setup.py and distribute it as a py_module along with the script.
Do you have better solutions?
Yes. Use setuptools in your setup.py, and declare the version there. Then, in your script, use:
from pkg_resources import require my_version = require('MyProjectName')[0].version
Where 'MyProjectName' is whatever 'name=' argument you passed to setup() in your setup.py.
Hello
If your script has taken care of separating functions and the mail call in a “if __name__ == '__main__'” block, you can just import your script and get its __version__ attribute.
Regards
On Wed, Jun 16, 2010 at 7:26 AM, Denis Jasselette dionysos_13@yahoo.fr wrote:
Do you have better solutions?
This is a perfectly fine solution. It is simple, and does not requires any 3rd party code.
David
Éric Araujo wrote:
If your script has taken care of separating functions and the mail call in a “if __name__ == '__main__'” block, you can just import your script and get its __version__ attribute.
It was my first guess but then, I would have to rename my script with a .py extension. Which is not great in an executable name.
P.J. Eby wrote:
Yes. Use setuptools in your setup.py, and declare the version there. Then, in your script, use:
from pkg_resources import require my_version = require('MyProjectName')[0].versionWhere 'MyProjectName' is whatever 'name=' argument you passed to setup() in your setup.py.
It works. However, I'd rather not force users to install setuptools if possible.
David Cournapeau wrote:
This is a perfectly fine solution. It is simple, and does not requires any 3rd party code.
It doesn't seem very clean though. But I suppose I could live with that.
I have another problem with this solution. Distutils seems to set permissions of py_modules to non-world-readable. Meaning that, as I have to launch the installation as root, I can't read it unless I launch the script as root as well. The weird part is that the script's permissions are just fine.
On Wed, Jun 16, 2010 at 11:29 PM, Denis Jasselette dionysos_13@yahoo.fr wrote:
Éric Araujo wrote:
If your script has taken care of separating functions and the mail call in a “if __name__ == '__main__'” block, you can just import your script and get its __version__ attribute.
It was my first guess but then, I would have to rename my script with a .py extension. Which is not great in an executable name.
P.J. Eby wrote:
Yes. Use setuptools in your setup.py, and declare the version there. Then, in your script, use:
from pkg_resources import require my_version = require('MyProjectName')[0].version
Where 'MyProjectName' is whatever 'name=' argument you passed to setup() in your setup.py.
It works. However, I'd rather not force users to install setuptools if possible.
David Cournapeau wrote:
This is a perfectly fine solution. It is simple, and does not requires any 3rd party code.
It doesn't seem very clean though.
I guess it is a matter of opinion, but I find it clearer than the other suggested solutions.
I have another problem with this solution. Distutils seems to set permissions of py_modules to non-world-readable. Meaning that, as I have to launch the installation as root, I can't read it unless I launch the script as root as well. The weird part is that the script's permissions are just fine.
What OS are you using and which set of commands did you exactly use ?
David
What OS are you using and which set of commands did you exactly use ?
I am using Ubuntu 10.04 (python 2.6). And here is what I did:
$ ll -rwxr-xr-x 1 denis denis 396 2010-06-16 14:39 setup.py -rwxr-xr-x 1 denis denis 10K 2010-06-16 14:13 teqhtml -rw-r--r-- 1 denis denis 203 2010-06-16 14:11 teqhtml_config.py $ ./setup.py build [...] $ sudo ./setup.py install [...] $ ll /usr/local/bin/ -rwxr-xr-x 1 root root 10K 2010-06-16 17:06 teqhtml $ ll /usr/local/lib/python2.6/dist-packages/ -rw------- 1 root staff 281 2010-06-16 17:06 teqhtml-0.5.egg-info -rw------- 1 root staff 203 2010-06-16 14:11 teqhtml_config.py -rw------- 1 root staff 562 2010-06-16 17:06 teqhtml_config.pyc
Actually, install doesn't change permissions, they are set while building. It looks like the umask is taken into account for py_modules but permissions are explicitly changed for scripts. If I set my umask to 0000 for instance, I don't have that problem.
On Thu, Jun 17, 2010 at 12:19 AM, Denis Jasselette dionysos_13@yahoo.fr wrote:
What OS are you using and which set of commands did you exactly use ?
I am using Ubuntu 10.04 (python 2.6). And here is what I did:
$ ll -rwxr-xr-x 1 denis denis 396 2010-06-16 14:39 setup.py -rwxr-xr-x 1 denis denis 10K 2010-06-16 14:13 teqhtml -rw-r--r-- 1 denis denis 203 2010-06-16 14:11 teqhtml_config.py $ ./setup.py build [...] $ sudo ./setup.py install [...] $ ll /usr/local/bin/ -rwxr-xr-x 1 root root 10K 2010-06-16 17:06 teqhtml $ ll /usr/local/lib/python2.6/dist-packages/ -rw------- 1 root staff 281 2010-06-16 17:06 teqhtml-0.5.egg-info -rw------- 1 root staff 203 2010-06-16 14:11 teqhtml_config.py -rw------- 1 root staff 562 2010-06-16 17:06 teqhtml_config.pyc
Actually, install doesn't change permissions, they are set while building. It looks like the umask is taken into account for py_modules but permissions are explicitly changed for scripts. If I set my umask to 0000 for instance, I don't have that problem.
What is your umask (when the .py are non world-readable) ? I believe sudo has a different way of handling umask (compared to using straight root account). You could try installing as root instead of using sudo, and/or checking your sudoers for umask settings,
David
David Cournapeau wrote :
What is your umask (when the .py are non world-readable) ? I believe sudo has a different way of handling umask (compared to using straight root account). You could try installing as root instead of using sudo, and/or checking your sudoers for umask settings,
My umask is 0077 and it's set globally, i.e., for the root account as well. I don't know exactly how sudo deals with it. However, I don't think sudo is the problem here, as I said before, permissions are set during the building.
Anyway, I solved this by setting a less restrictive umask (if available) explicitly in setup.py.
There is another solution that doesn’t require the overkill of adding a mostly useless module or switching away from standard distutils: You can grep for “__version__ = ” in your script (either with real grep or a few lines of Python). Not sure this caters to your use case, but at least it’s recorded in the thread.
Regards
Éric Araujo wrote :
There is another solution that doesn’t require the overkill of adding a mostly useless module or switching away from standard distutils: You can grep for “__version__ = ” in your script (either with real grep or a few lines of Python). Not sure this caters to your use case, but at least it’s recorded in the thread.
`overkill' is just the right term ^^. I like this solution, even though it's a bit rough. I finally did this (using a python implementation for portability reasons).
-
David Cournapeau -
Denis Jasselette -
P.J. Eby -
Éric Araujo