Re: [Distutils] Parsing setup()

Phillip J. Eby wrote:
If you use "-e sometmpdir" as an option, you can have the .egg-info put in a temporary directory with a known location. You need this because some package layouts don't have the .egg-info in the package root, so the rest of your stuff won't work.
To be honest, though, I think you're going to way too much trouble here. Just what exactly is the use case here? Couldn't you just easy_install the package to a temporary directory with --no-deps? Why do you think you need to inspect the setup.py in the first place?
Sorry, I should have explained what I was attempting. The code is going to be used for g-pypi[1], a tool I wrote specifically for creating ebuilds for Gentoo's portage package manager. It creates ebuilds by using setuptools and querying The Cheese Shop. We still use setuptools/distutils normally, I'm just grabbing the dependency info to help create the ebuilds which still have to have all the dependency info in them (portage doesn't use easy_install).
(You might also want to consider using the setuptools.sandbox.run_setup() function instead of os.system.)
That looks much better, I'll check that out.
In general, I would suggest that trying to work your way around setuptools' APIs is a very bad idea. More often than not, you will miss one of the nine jillion supported configurations and thus will end up with a tool that only works on your system... *sometimes*.
Case in point: your code above depends on the .egg-info being in the setup directory, which is often not the case. Zope packages, for example, usually have a src/ or lib/ subdirectory that will be where the egg-info is. Other packages may have it in other places, perhaps even more deeply nested.
Pretty much *any* place where you are reading a file format directly or looking at directory contents yourself, you're probably breaking something that setuptools has encapsulated for a Very Good Reason. When in doubt, ask. :)
I'll keep all that in mind. I was thinking of making the code more general in the future in case someone else wanted to use it for a different package manager and needed to find out all the dependencies before creating rpm's or debs etc. So far it's working good - it's better than downloading, unpacking and reading all the setup.py's by hand, which we'd been doing ;) Thanks, Phillip! [1] g-pypi: http://tools.assembla.com/g-pypi
participants (1)
-
Rob