I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
Changes include numerous bug fixes and tweaks for corner cases in easy_install processing, mostly discovered by Jim Fulton in the process of developing his "zc.buildout" tool (a Make-like system that supports simple installation of complex environments).
In addition, there is now a formally-documented "package index API" that easy_install supports:
http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
So, people who wish to create their own "package indexes" for easy_install can do so, even using static HTML -- even without a web server.
Last, but not least, the ability was added to turn off SVN revision numbers or dates from the command line, so that you don't have to edit setup.cfg in order to issue a release.
There are a few outstanding requests that I was *not* able to consider for 0.6 because the required changes would've been too disruptive to stability. They have been bumped to the 0.7 list to receive further consideration after 0.6 final is released:
* A request to change the PYTHONPATH resolution order * A request to allow installed scripts to use -O * Adding XML-RPC support for PyPI
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
Last, but not least, the ability was added to turn off SVN revision numbers or dates from the command line, so that you don't have to edit setup.cfg in order to issue a release.
Would've been convenient if you said what the option was... took me a few minutes to figure out where to look. Presumably you're referring to the --no-svn-revision option?
Options for 'egg_info' command: --egg-base (-e) directory containing .egg-info directories (default: top of the source tree) --tag-svn-revision (-r) Add subversion revision ID to version number --tag-date (-d) Add date stamp (e.g. 20050528) to version number --tag-build (-b) Specify explicit tag to add to version number --no-svn-revision (-R) Don't add subversion revision ID [default] --no-date (-D) Don't include date stamp [default] --tag-build (-b) Specify explicit tag to add to version number
Note that tag-build shows up twice, here's a patch:
Index: setuptools/command/egg_info.py =================================================================== --- setuptools/command/egg_info.py (revision 50587) +++ setuptools/command/egg_info.py (working copy) @@ -28,7 +28,6 @@ ('no-svn-revision', 'R', "Don't add subversion revision ID [default]"), ('no-date', 'D', "Don't include date stamp [default]"), - ('tag-build=', 'b', "Specify explicit tag to add to version number"), ] boolean_options = ['tag-date', 'tag-svn-revision']
-bob
At 12:33 PM 7/11/2006 -0700, Bob Ippolito wrote:
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
Last, but not least, the ability was added to turn off SVN revision numbers or dates from the command line, so that you don't have to edit setup.cfg in order to issue a release.
Would've been convenient if you said what the option was... took me a few minutes to figure out where to look. Presumably you're referring to the --no-svn-revision option?
Yep. See also:
http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-relea...
In particular, the new subsection:
http://peak.telecommunity.com/DevCenter/setuptools#making-official-non-snaps...
Quick tip: you can use:
http://peak.telecommunity.com/DevCenter/setuptools?action=diff
to check on the latest changes to setuptools' doc after a release. The wiki also allows you to subscribe to receive change notices via email. This also goes for the EasyInstall and PkgResources doc pages.
Note that tag-build shows up twice, here's a patch:
Argh. :( Thanks for catching that. I've fixed it in the trunk and 0.6 branch.
On Jul 11, 2006, at 12:33 PM, Bob Ippolito wrote:
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
Last, but not least, the ability was added to turn off SVN revision numbers or dates from the command line, so that you don't have to edit setup.cfg in order to issue a release.
Would've been convenient if you said what the option was... took me a few minutes to figure out where to look. Presumably you're referring to the --no-svn-revision option?
It seems that --no-svn-revision is only part of the solution to making releases less of a hassle. The problem is that setup.cfg is still included in sdist, so any user that builds your egg from source is going to have it tagged with ".dev_r0". This is especially problematic for dependencies because it may download the correct version of source, but ".dev_r0" ranks lower so it will say the dependency is not satisfied.
What's the best solution to this, barring deleting setup.cfg from the release branch?
-bob
At 07:17 AM 7/17/2006 -0700, Bob Ippolito wrote:
It seems that --no-svn-revision is only part of the solution to making releases less of a hassle. The problem is that setup.cfg is still included in sdist, so any user that builds your egg from source is going to have it tagged with ".dev_r0". This is especially problematic for dependencies because it may download the correct version of source, but ".dev_r0" ranks lower so it will say the dependency is not satisfied.
What's the best solution to this, barring deleting setup.cfg from the release branch?
Argh. Well, you could put an exclude in MANIFEST.in to drop the setup.cfg, but that sucks. Maybe the right thing to do is to include the setup.cfg, but to update it with the tag and version settings that were in effect when the sdist was built.
On Jul 17, 2006, at 2:35 PM, Phillip J. Eby wrote:
At 07:17 AM 7/17/2006 -0700, Bob Ippolito wrote:
It seems that --no-svn-revision is only part of the solution to making releases less of a hassle. The problem is that setup.cfg is still included in sdist, so any user that builds your egg from source is going to have it tagged with ".dev_r0". This is especially problematic for dependencies because it may download the correct version of source, but ".dev_r0" ranks lower so it will say the dependency is not satisfied.
What's the best solution to this, barring deleting setup.cfg from the release branch?
Argh. Well, you could put an exclude in MANIFEST.in to drop the setup.cfg, but that sucks. Maybe the right thing to do is to include the setup.cfg, but to update it with the tag and version settings that were in effect when the sdist was built.
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
-bob
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
On Jul 17, 2006, at 2:35 PM, Phillip J. Eby wrote:
Argh. Well, you could put an exclude in MANIFEST.in to drop the setup.cfg, but that sucks. Maybe the right thing to do is to include the setup.cfg, but to update it with the tag and version settings that were in effect when the sdist was built.
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
That depends on how big the change ends up being. If it looks simple and unlikely to fail, I could live with adding it to 0.6.
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and 0.6c1dev-r50703. It even handles date and SVN revision tags correctly, by converting them to a single --tag-build string and disabling the other tagging options. So if you just build from an sdist without doing anything special, you get the exact same version the sdist was built with, regardless of how the version was originally specified.
Phillip J. Eby wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and 0.6c1dev-r50703. It even handles date and SVN revision tags correctly, by converting them to a single --tag-build string and disabling the other tagging options. So if you just build from an sdist without doing anything special, you get the exact same version the sdist was built with, regardless of how the version was originally specified.
I'm glad this is being worked on. But a related issue is still biting me with setuptools 0.6c1 in my stdeb package (which builds debian source packages from unmodified setup.py scripts) :
Any distutils commands using "self.distribution.get_version()" still get tagged (at least with the svn revision), even if they're being built from the sdist-generated .tar.gz package.
Not knowing the innards of setuptools very well, one idea would be to add something to the .egg-info built by sdist that tells future runs of setuptools not to add tags. This keeps setup.cfg from getting modified but still has the right effect. There's probably a flaw I haven't thought of, though...
Cheers! Andrew
At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
Phillip J. Eby wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and 0.6c1dev-r50703. It even handles date and SVN revision tags correctly, by converting them to a single --tag-build string and disabling the other tagging options. So if you just build from an sdist without doing anything special, you get the exact same version the sdist was built with, regardless of how the version was originally specified.
I'm glad this is being worked on. But a related issue is still biting me with setuptools 0.6c1 in my stdeb package (which builds debian source packages from unmodified setup.py scripts) :
Any distutils commands using "self.distribution.get_version()" still get tagged (at least with the svn revision), even if they're being built from the sdist-generated .tar.gz package.
I'm having trouble following your question. If you generate an sdist with an SVN revision in the distribution name, then anything you run on the unpacked sdist should result in the same version number that generated the sdist.
So if I build a source distribution for "setuptools-0.6c1dev-r50703.tar.gz", then anything you do with that source distribution should end up with 0.6c1dev-r50703 as the version number. If you have something that *doesn't* end up with that version number, it's a bug. If it *does* have that version number, then it's doing the right thing. The point of this change was to make it so that anything you build from an sdist has the same version number as the sdist was built with.
Not knowing the innards of setuptools very well, one idea would be to add something to the .egg-info built by sdist that tells future runs of setuptools not to add tags. This keeps setup.cfg from getting modified but still has the right effect. There's probably a flaw I haven't thought of, though...
I'm still not understanding what you're getting at; this should be working correctly now in 0.6c1, so if it's not, please give me some steps to reproduce so I can find out what's wrong. Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phillip J. Eby wrote:
At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
Phillip J. Eby wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and 0.6c1dev-r50703. It even handles date and SVN revision tags correctly, by converting them to a single --tag-build string and disabling the other tagging options. So if you just build from an sdist without doing anything special, you get the exact same version the sdist was built with, regardless of how the version was originally specified.
I'm glad this is being worked on. But a related issue is still biting me with setuptools 0.6c1 in my stdeb package (which builds debian source packages from unmodified setup.py scripts) :
Any distutils commands using "self.distribution.get_version()" still get tagged (at least with the svn revision), even if they're being built from the sdist-generated .tar.gz package.
'get_version()' returns the Python version, right? Using it makes the egg "version-specific."
I'm having trouble following your question. If you generate an sdist with an SVN revision in the distribution name, then anything you run on the unpacked sdist should result in the same version number that generated the sdist.
So if I build a source distribution for "setuptools-0.6c1dev-r50703.tar.gz", then anything you do with that source distribution should end up with 0.6c1dev-r50703 as the version number. If you have something that *doesn't* end up with that version number, it's a bug. If it *does* have that version number, then it's doing the right thing. The point of this change was to make it so that anything you build from an sdist has the same version number as the sdist was built with.
Not knowing the innards of setuptools very well, one idea would be to add something to the .egg-info built by sdist that tells future runs of setuptools not to add tags. This keeps setup.cfg from getting modified but still has the right effect. There's probably a flaw I haven't thought of, though...
I'm still not understanding what you're getting at; this should be working correctly now in 0.6c1, so if it's not, please give me some steps to reproduce so I can find out what's wrong. Thanks.
I think he's talking about the fact that the *python version number" gets embedded in the egg name, rather than the SVN revision ID for the egg.
Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com
Phillip J. Eby wrote:
At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
Phillip J. Eby wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn-
revision).
Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and
0.6c1dev-r50703. It
even handles date and SVN revision tags correctly, by converting
them to a
single --tag-build string and disabling the other tagging options.
So if
you just build from an sdist without doing anything special, you
get the
exact same version the sdist was built with, regardless of how the
version
was originally specified.
I'm glad this is being worked on. But a related issue is still biting me with setuptools 0.6c1 in my stdeb package (which builds debian source packages from unmodified setup.py scripts) :
Any distutils commands using "self.distribution.get_version()" still get tagged (at least with the svn revision), even if they're being built from the sdist-generated .tar.gz package.
I'm having trouble following your question. If you generate an sdist with an SVN revision in the distribution name, then anything you run on the unpacked sdist should result in the same version number that generated the sdist.
So if I build a source distribution for "setuptools-0.6c1dev-r50703.tar.gz", then anything you do with that source distribution should end up with 0.6c1dev-r50703 as the version number. If you have something that *doesn't* end up with that version number, it's a bug. If it *does* have that version number, then it's doing the right thing. The point of this change was to make it so that anything you build from an sdist has the same version number as the sdist was built with.
OK, I guess I have an issue with "sdist" build packages made with plain old distutils vs. setuptools. See below.
Not knowing the innards of setuptools very well, one idea would be to add something to the .egg-info built by sdist that tells future runs of setuptools not to add tags. This keeps setup.cfg from getting modified but still has the right effect. There's probably a flaw I haven't thought of, though...
I'm still not understanding what you're getting at; this should be working correctly now in 0.6c1, so if it's not, please give me some steps to reproduce so I can find out what's wrong. Thanks.
Steps to reproduce:
1) download and expand matplotlib-0.87.4.tar.gz; cd into that directory. (This was built with plain old distutils sdist.) 2) python -c "import setuptools; execfile('setup.py')" egg_info 3) diff -u PKG-INFO lib/matplotlib.egg-info/PKG-INFO
--- PKG-INFO 2006-07-11 19:24:15.000000000 -0700 +++ lib/matplotlib.egg-info/PKG-INFO 2006-07-21 12:49:07.000000000 -0700 @@ -1,6 +1,6 @@ Metadata-Version: 1.0 Name: matplotlib -Version: 0.87.4 +Version: 0.87.4.dev-r0 Summary: Matlab(TM) style python plotting package Home-page: http://matplotlib.sourceforge.net Author: John D. Hunter
(I'm just using the egg_info command as an example here, but there are other ways to get at Command.distribution.get_version().)
Note that building the source distribution with python -c "import setuptools; execfile('setup.py')" sdist DOES result in the same version numbers. (The version number becomes "0.87.4.dev-r0" -- the source has a setup.cfg with "tag_build = .dev" and "tag_svn_revision = 1"). I see now that this could be considered a matplotlib bug -- it has a setup.cfg with setuptools options but distributes packages not built with setuptools. Let me know if you think this is a matplotlib bug.
OK, now after some more playing around, I can see that I can generate an sdist using the following (we don't want ".dev-r0" in release name, after all).
python -c "import setuptools; execfile('setup.py')" egg_info --tag-build='' --no-svn-revision sdist
So is this the recommended sdist-building procedure for packages that ship a setup.cfg with [egg_info] options set?
At 01:10 PM 7/21/2006 -0700, Andrew Straw wrote:
- download and expand matplotlib-0.87.4.tar.gz; cd into that directory.
(This was built with plain old distutils sdist.)
Okay, that's where the problem lies, then. If you use distutils sdist, you get what the distutils sdist does. :)
If you build an sdist using setuptools (0.6c1), then that sdist will have the same version number as the original.
If you build an sdist using distutils OR a version of setuptools less than 0.6c1, you will get... something else. :)
Note that building the source distribution with python -c "import setuptools; execfile('setup.py')" sdist DOES result in the same version numbers. (The version number becomes "0.87.4.dev-r0" -- the source has a setup.cfg with "tag_build = .dev" and "tag_svn_revision = 1"). I see now that this could be considered a matplotlib bug -- it has a setup.cfg with setuptools options but distributes packages not built with setuptools. Let me know if you think this is a matplotlib bug.
Sort of. It's more a question of what behavior they want. I think they are trying to walk a fine line of being able to use setuptools without requiring users to have it.
OK, now after some more playing around, I can see that I can generate an sdist using the following (we don't want ".dev-r0" in release name, after all).
python -c "import setuptools; execfile('setup.py')" egg_info --tag-build='' --no-svn-revision sdist
So is this the recommended sdist-building procedure for packages that ship a setup.cfg with [egg_info] options set?
Not unless the package creator requests it. Otherwise, you could be stripping version information that's *supposed* to be there. This is why setuptools now ships an automatically modified setup.cfg when it builds an sdist, so that what you get by default is whatever the builder of the sdist wanted.
So, in the current situation with matplotlib, one of two things needs to happen:
* They need to build their sdist with setuptools, OR * They need to strip the egg_info settings from setup.cfg before building an untagged release with the distutils
Either way should result in an sdist that works correctly for setuptools, but it may be that they have to take the latter option in order to avoid requiring setuptools. (I'm not sure whether that's the case or not.)
In any case, until 0.6c1, the latter option was the only *possible* option, and it's discussed at some length in the setuptools manual, including alternative ways to manage the process with Subversion.
On Jul 21, 2006, at 12:40 PM, Phillip J. Eby wrote:
At 11:20 AM 7/21/2006 -0700, Andrew Straw wrote:
Phillip J. Eby wrote:
At 02:49 PM 7/17/2006 -0700, Bob Ippolito wrote:
That's not a bad idea (update setup.cfg on sdist w/ --no-svn- revision). Any chance of getting this in setuptools 0.6 or should I start adding MANIFEST.in files to the relevant projects?
Okay, it's in the trunk now as of 0.7a1dev-r50702 and 0.6c1dev- r50703. It even handles date and SVN revision tags correctly, by converting them to a single --tag-build string and disabling the other tagging options. So if you just build from an sdist without doing anything special, you get the exact same version the sdist was built with, regardless of how the version was originally specified.
I'm glad this is being worked on. But a related issue is still biting me with setuptools 0.6c1 in my stdeb package (which builds debian source packages from unmodified setup.py scripts) :
Any distutils commands using "self.distribution.get_version()" still get tagged (at least with the svn revision), even if they're being built from the sdist-generated .tar.gz package.
I'm having trouble following your question. If you generate an sdist with an SVN revision in the distribution name, then anything you run on the unpacked sdist should result in the same version number that generated the sdist.
So if I build a source distribution for "setuptools-0.6c1dev-r50703.tar.gz", then anything you do with that source distribution should end up with 0.6c1dev-r50703 as the version number. If you have something that *doesn't* end up with that version number, it's a bug. If it *does* have that version number, then it's doing the right thing. The point of this change was to make it so that anything you build from an sdist has the same version number as the sdist was built with.
Not knowing the innards of setuptools very well, one idea would be to add something to the .egg-info built by sdist that tells future runs of setuptools not to add tags. This keeps setup.cfg from getting modified but still has the right effect. There's probably a flaw I haven't thought of, though...
I'm still not understanding what you're getting at; this should be working correctly now in 0.6c1, so if it's not, please give me some steps to reproduce so I can find out what's wrong. Thanks.
It sounds like Andrew just forgot to use --no-svn-revision...
-bob
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
It seems there's another bug in 0.6b4. I don't know what conditions cause it, however:
File "/Volumes/Data/developer-external/py2app/setuptools-0.6b4- py2.4.egg/setuptools/dist.py", line 274, in fetch_build_egg AttributeError: Distribution instance has no attribute 'dependency_links'
It looks like there's no default for dependency_links in some cases.. so that needs to change to a getattr, or it needs to set some default.
-bob
On Jul 12, 2006, at 9:00 PM, Bob Ippolito wrote:
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
It seems there's another bug in 0.6b4. I don't know what conditions cause it, however:
File "/Volumes/Data/developer-external/py2app/setuptools-0.6b4- py2.4.egg/setuptools/dist.py", line 274, in fetch_build_egg AttributeError: Distribution instance has no attribute 'dependency_links'
It looks like there's no default for dependency_links in some cases.. so that needs to change to a getattr, or it needs to set some default.
Ok, it seems this happens whenever you do develop, install, etc. when all dependencies aren't available. easy_install seems to work though.
This patch seems to make everything work as expected:
=================================================================== --- setuptools/dist.py (revision 50587) +++ setuptools/dist.py (working copy) @@ -271,7 +271,7 @@ for key in opts.keys(): if key not in keep: del opts[key] # don't use any other settings - if self.dependency_links: + if getattr(self, 'dependency_links', None): links = self.dependency_links[:] if 'find_links' in opts: links = opts['find_links'][1].split() + links
-bob
At 09:09 PM 7/12/2006 -0700, Bob Ippolito wrote:
On Jul 12, 2006, at 9:00 PM, Bob Ippolito wrote:
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
It seems there's another bug in 0.6b4. I don't know what conditions cause it, however:
File "/Volumes/Data/developer-external/py2app/setuptools-0.6b4- py2.4.egg/setuptools/dist.py", line 274, in fetch_build_egg AttributeError: Distribution instance has no attribute 'dependency_links'
It looks like there's no default for dependency_links in some cases.. so that needs to change to a getattr, or it needs to set some default.
Ok, it seems this happens whenever you do develop, install, etc. when all dependencies aren't available. easy_install seems to work though.
As it turns out, it's due to the hairy problem of bootstrapping arguments that depend on entry points, before the requirements that initialize the entry points are initialized. I'm fixing it at the point of initialization instead of downstream, since then any new code that needs to access self.dependency_links won't end up with the same bug.
On Jul 11, 2006, at 12:12 PM, Phillip J. Eby wrote:
I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
Here's another patch I'd like to see ASAP. Some vendors have Q&A procedures that disallow empty files without special exception, so we should ensure that setuptools doesn't create empty safety flag files.
Index: setuptools/command/bdist_egg.py =================================================================== --- setuptools/command/bdist_egg.py (revision 50611) +++ setuptools/command/bdist_egg.py (working copy) @@ -360,7 +360,9 @@ if safe is None or bool(safe)<>flag: os.unlink(fn) elif safe is not None and bool(safe)==flag: - open(fn,'w').close() + f = open(fn,'w') + f.write(fn) + f.close() safety_flags = { True: 'zip-safe',
-bob
On Jul 11, 2006, at 3:12 PM, Phillip J. Eby wrote:
I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
With the new version, I'm still having the problem that the --no-deps option is ignored by setup.py develop.
Jim
-- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
At 03:57 PM 7/13/2006 -0400, Jim Fulton wrote:
On Jul 11, 2006, at 3:12 PM, Phillip J. Eby wrote:
I have just released version 0.6b4 of setuptools, the last beta release of setuptools 0.6. Please upgrade and test at your earliest convenience, as I would like to issue a release candidate version next week.
With the new version, I'm still having the problem that the --no-deps option is ignored by setup.py develop.
That's because I never fixed it. :) Apparently I didn't get it on my list. I've checked in a fix now, along with fixes for the problems Bob found.
participants (5)
-
Andrew Straw -
Bob Ippolito -
Jim Fulton -
Phillip J. Eby -
Tres Seaver