docs on using setuptools in a release cycle with RPMS
I am trying to get egg generation entry points integrated with building RPM's, and hopefully debian packages too. I haven't had much luck finding any documentation on this though. My specific question is: Can I use: python2.5 ./setup.py bdist_rpm --binary-only --release=py25 --python=/ usr/local/bin/python2.5 and expect that an console script entry point I define in setup.py will install to the bin directory for an rpm as well? If someone has some documents or a build script I could look at, I would appreciate it. Noah
At 04:16 AM 1/17/2008 -0500, Noah Gift wrote:
I am trying to get egg generation entry points integrated with building RPM's, and hopefully debian packages too. I haven't had much luck finding any documentation on this though. My specific question is:
Can I use:
python2.5 ./setup.py bdist_rpm --binary-only --release=py25 --python=/ usr/local/bin/python2.5
and expect that an console script entry point I define in setup.py will install to the bin directory for an rpm as well?
Give it a try and see. :) (Yes, setuptools does support bdist_rpm.)
On Jan 17, 2008, at 9:32 AM, Phillip J. Eby wrote:
At 04:16 AM 1/17/2008 -0500, Noah Gift wrote:
I am trying to get egg generation entry points integrated with building RPM's, and hopefully debian packages too. I haven't had much luck finding any documentation on this though. My specific question is:
Can I use:
python2.5 ./setup.py bdist_rpm --binary-only --release=py25 -- python=/ usr/local/bin/python2.5
and expect that an console script entry point I define in setup.py will install to the bin directory for an rpm as well?
Give it a try and see. :) (Yes, setuptools does support bdist_rpm.)
I knew you were going to say that :) I was actually struggling a bit early this morning trying to figure out exactly how it works. I was hoping I wouldn't have to actually give a traceback and reveal a stupid mistake :) My, for now, build cycle, until I automate it, is that I create a build/lib directory: Step 1: mkdir -p build/lib Step 2: Place script inside of build/lib cp script.py build/lib Step 3: In current directory run: python2.4 ./setup.py bdist_rpm --binary-only --release=py24 --python=/ usr/local/bin/python2.4 Step 4: Grab rpm out of newly created dist directory: This process works just fine if I substitute: python2.4 ./setup.py bdist_egg In my setup.py I have an entry point as follows: entry_points=""" [console_scripts] liten = liten:main """, ) I can easy install a python2.4 or a python 2.5 egg without a glitch, but when I install the rpm I created I am able to run my script, but I get this traceback: [robroy@giftcsllc02 ~]$ liten Traceback (most recent call last): File "/usr/bin/liten", line 7, in ? sys.exit( File "/usr/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/ pkg_resources.py", line 277, in load_entry_point return get_distribution(dist).load_entry_point(group, name) File "/usr/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/ pkg_resources.py", line 2179, in load_entry_point return ep.load() File "/usr/lib/python2.4/site-packages/setuptools-0.6c7-py2.4.egg/ pkg_resources.py", line 1912, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) ImportError: No module named liten My guess is that somehow I am not creating the RPM properly, and I need to have a different directly structure then when creating an egg? Thanks, Noah
At 09:54 AM 1/17/2008 -0500, Noah Gift wrote:
On Jan 17, 2008, at 9:32 AM, Phillip J. Eby wrote:
At 04:16 AM 1/17/2008 -0500, Noah Gift wrote:
I am trying to get egg generation entry points integrated with building RPM's, and hopefully debian packages too. I haven't had much luck finding any documentation on this though. My specific question is:
Can I use:
python2.5 ./setup.py bdist_rpm --binary-only --release=py25 -- python=/ usr/local/bin/python2.5
and expect that an console script entry point I define in setup.py will install to the bin directory for an rpm as well?
Give it a try and see. :) (Yes, setuptools does support bdist_rpm.)
I knew you were going to say that :) I was actually struggling a bit early this morning trying to figure out exactly how it works. I was hoping I wouldn't have to actually give a traceback and reveal a stupid mistake :)
My, for now, build cycle, until I automate it, is that I create a build/lib directory:
Step 1:
mkdir -p build/lib
Step 2:
Place script inside of build/lib
cp script.py build/lib
Why are you doing these steps? I don't understand.
Step 3:
In current directory run:
python2.4 ./setup.py bdist_rpm --binary-only --release=py24 --python=/ usr/local/bin/python2.4
Step 4:
Grab rpm out of newly created dist directory:
This process works just fine if I substitute:
python2.4 ./setup.py bdist_egg
In my setup.py I have an entry point as follows:
entry_points=""" [console_scripts] liten = liten:main """, )
What's the rest of your setup.py?
My guess is that somehow I am not creating the RPM properly, and I need to have a different directly structure then when creating an egg?
My guess is that your 'liten' module isn't listed in the py_modules argument to setup(). Is it?
cp script.py build/lib
Why are you doing these steps? I don't understand.
In order to create an egg, to my knowledge, you create a build/lib directory and place your scripts or library inside, then run setup.py bdist_egg. Those were the steps I took, to successfully create a python 2.4 and a python 2.5 egg.
Step 3:
In current directory run:
python2.4 ./setup.py bdist_rpm --binary-only --release=py24 -- python=/ usr/local/bin/python2.4
Step 4:
Grab rpm out of newly created dist directory:
This process works just fine if I substitute:
python2.4 ./setup.py bdist_egg
In my setup.py I have an entry point as follows:
entry_points=""" [console_scripts] liten = liten:main """, )
What's the rest of your setup.py?
Here is the rest: from setuptools import Extension, find_packages, setup setup(name='liten', version='0.1.3', description='a de-duplication command line tool', long_description="This command line tool will examine a file system and \ report back duplicates using a md5 checksum hash algorithm.", author='Noah Gift', author_email='noah.gift@gmail.com', url='http://code.google.com/p/liten/', license='MIT', packages=find_packages(), zip_safe=False, entry_points=""" [console_scripts] liten = liten:main """, )
My guess is that somehow I am not creating the RPM properly, and I need to have a different directly structure then when creating an egg?
My guess is that your 'liten' module isn't listed in the py_modules argument to setup(). Is it?
That is correct. I am able to create eggs with entry points that work just fine without specifying my module, but are you saying that in order to use the bdist_rpm command that I also need to include: py_modules=['liten'] Of course, I am going to try adding this right now.
At 01:07 PM 1/17/2008 -0500, Noah Gift wrote:
cp script.py build/lib
Why are you doing these steps? I don't understand.
In order to create an egg, to my knowledge, you create a build/lib directory and place your scripts or library inside, then run setup.py bdist_egg.
Where did you get that knowledge? We should correct whatever source you got that from, because that is absolutely *not* the way to do it, and is in fact a good way to lose your work. (E.g. "setup.py clean" will delete it.)
That is correct. I am able to create eggs with entry points that work just fine without specifying my module, but are you saying that in order to use the bdist_rpm command that I also need to include:
py_modules=['liten']
No, what I'm saying is that you should have that line in your setup.py, period, and you should not mess with the contents of build/lib or really *anything* under build. The build/ directory is used by the distutils to build things. Your source code goes directly alongside setup.py, generally speaking. You may want to review the "Distributing Python Modules" documentation at: http://docs.python.org/dist/ As you'll find there, there is no mention of putting things into build/ - you put things in the directory where your setup.py is, and the distutils (or setuptools) are responsible for copying them into build/ and other places. There are absolutely no user-serviceable parts in build/. What you've been doing is a bit like taking a power drill and then turning it by the handle instead of plugging it in and pulling the trigger. In some cases it may seem to be work, but mostly you are just making things harder than they need to be. :)
In order to create an egg, to my knowledge, you create a build/lib directory and place your scripts or library inside, then run setup.py bdist_egg.
Where did you get that knowledge? We should correct whatever source you got that from, because that is absolutely *not* the way to do it, and is in fact a good way to lose your work. (E.g. "setup.py clean" will delete it.)
I may have just assumed this, by looking at examples and reading output from stdout. This may have been a trial and error solution, so I am glad I asked and found out this was incorrect. Of course, I come from a R/D and Systems Administration background so I am pretty used to doing really, really bad things I am not supposed to do :)
That is correct. I am able to create eggs with entry points that work just fine without specifying my module, but are you saying that in order to use the bdist_rpm command that I also need to include:
py_modules=['liten']
No, what I'm saying is that you should have that line in your setup.py, period, and you should not mess with the contents of build/ lib or really *anything* under build. The build/ directory is used by the distutils to build things. Your source code goes directly alongside setup.py, generally speaking.
Ok, this is good to know. That is much more intuitive. I may have run into some issue that made me think creating a build/lib directory would help.
You may want to review the "Distributing Python Modules" documentation at:
As you'll find there, there is no mention of putting things into build/ - you put things in the directory where your setup.py is, and the distutils (or setuptools) are responsible for copying them into build/ and other places. There are absolutely no user-serviceable parts in build/.
What you've been doing is a bit like taking a power drill and then turning it by the handle instead of plugging it in and pulling the trigger. In some cases it may seem to be work, but mostly you are just making things harder than they need to be. :)
Believe it or not, I am writing a chapter on Eggs, Buildout, and Virtualenv for our O'Reilly book. I hope to do a good job of explaining how to use eggs/buildout/virtualenv and build RPM's and other packages such as AIX/HP-UX, Debian/Ubuntu. I might be asking a few more dumb questions, so I will try to read as much as I can to limit the total number. I think a large source of confusion for me, was thinking that distutils was somehow deprecated, and that I don't even need to read the docs. I have heard so many horror stories about distutils, that I have mistakenly thought they are somehow broken badly, and it is not worth reading, and that they are replaced by setuptools. I suppose there is going to be some confusion for me in trying to understand the intersection between disutils and setuptools, as I am not sure what I am expected to know from distutils and what setuptools replaces. I was operating under, obviously a false assumption, that setuptools was the was forward and was completely ignoring distutils. ok, off to read the distutils docs....
At 03:04 PM 1/17/2008 -0500, Noah Gift wrote:
I suppose there is going to be some confusion for me in trying to understand the intersection between disutils and setuptools, as I am not sure what I am expected to know from distutils and what setuptools replaces.
The setuptools docs really only document the differences between distutils and setuptools. So if you read them looking for what setuptools claims you *don't* have to do, then you can skip those parts of the distutils. For example, if you are using a revision control system to manage your source files, then you don't need to know the details of how to create a MANIFEST.in file -- something that's mandatory with the distutils in order to create a source distribution or something like an RPM. Regarding your eggs/buildout/etc. chapter, please feel free to email me an early copy for technical review and I'll promptly inform you about any errors. (Unless it's late next week or any time the following week, as I will be busy and not responding to virtually any email whatsoever :) .)
participants (2)
-
Noah Gift
-
Phillip J. Eby