Mailman 3 July 2009 - Distutils-SIG

Re: [Distutils] Colour this bikeshed: Name for setuptools fork
by P.J. Eby 18 Jul '09

18 Jul '09

At 07:28 PM 7/17/2009 +0200, Tarek Ziadé wrote: >On Fri, Jul 17, 2009 at 6:35 PM, P.J. Eby<pje(a)telecommunity.com> wrote: > > [...] > > > > However, AFAIK, nobody qualified for the job of setuptools maintainer > > actually *wants* the position, myself included. (This is not to say that > > such qualified persons do not exist, I'm just saying that I don't know of > > them at the moment.) > > > > But lack of qualified volunteers is not me "preventing" anyone doing > > anything. Obviously, I am not "preventing" anyone from forking it. > >I don't buy that anymore. If you want to be a dictator you have to be >present in the >maintenance of the code. You're not anymore present, now you are >acting and talking like an old >despot that don't want to see his kingdom taken over by the people ;) Eh? I encourage the fork. I only don't want it called setuptools. Call it the People's Republic of Setuptools or something. ;-) >More seriously, if you think people like me or Hanno are not qualified >enough to fix dumb-stupid bugs like >the svn 1.6 compatibility stuff, or do releases, that's your problem. As I said, at least half the patches I get are good. Knowing *which* half is the part that has tougher qualifications. ;-) >Also, you spend enough time in the mailing lists to be able to drive >us to do the "right" things, I don't intend to spend a lot of time on that for the fork, actually, at least not on an unsolicited basis. >so, I don't buy what you are saying about being "blessed" (being Ian >or Jim). I don't get what you mean by this.

3 3

Distribute - issue tracker
by Hanno Schlichting 17 Jul '09

17 Jul '09

Hi there. In order to not disrupt the setuptools project in any way, we have chosen to have our own issue tracker at http://bitbucket.org/tarek/distribute/issues and mirror issues instead. We felt that comments like "this is fixed in Distribute - come join us" are inappropriate to leave in the setuptools tracker ;-) Obviously this leaves us with a synchronization problem. We already do have a new issue and comments on issues which are unique in our own tracker. For now I've used a stupid low-tech approach and manually created a Wiki page at http://bitbucket.org/tarek/distribute/wiki/bug_listing which lists our own issues and their relations to the setuptools issue tracker. This is of course in addition to a comment on each issue explaining its origin. If someone has a better idea on how to synchronize these trackers or can provide insight in proven techniques for forks in this way, please speak up. Otherwise I'm going to continue to manually mirror all issues over from the setuptools tracker into our own. Cheers, Hanno

1 0

Re: [Distutils] Colour this bikeshed: Name for setuptools fork
by P.J. Eby 17 Jul '09

17 Jul '09

At 06:42 PM 7/17/2009 +0200, Lennart Regebro wrote: >This is an unreasonable position. You are adopting the position that >only the persons that you know do not have time to maintain it should >be allowed to do so, You seem to be confused. I'm only talking about the setuptools *primary maintainer* role. If said primary maintainer wants to have a more open patch policy, that'd be their business. (Heck, I'd grant the role to a *team* of qualified volunteers, if it cut down the load for said volunteers.) I've also laid out criteria -- both in the email you're replying to, and in the past -- for what would make me consider someone for the role of a primary maintainer. That nobody has stepped forward doesn't make me unreasonable, it means there's a lack of qualified and interested volunteers for that position. I'm not saying that nobody but Jim and Ian and Philip contribute good patches; maybe half the patches I get are basically good. But *reviewing* those patches, rejecting the ones that should be rejected, and hardest of all, coming up with good ways to actually move the codebase forward, are the tasks that need more-qualified (by my previously-stated definition) volunteers. > That has put us through a lot of unnecessary >pain, just because you are not willing to let go of something you no >longer are willing to maintain. Who said I'm not willing to maintain it? All I said is that it's not very high on my priorities for *unpaid* programming projects. That means that stuff tends to get fixed only when it interferes with me personally getting something done. >Setuptools is dead, Nope, is's only resting. ;-) At some point it'll move again. >you are not interested in maintaining it, Which should not be confused with me not having an *interest* in maintaining it. (Which is why the name only goes to a qualified replacement figurehead.)

1 0

[issue81] cannot install abstract.jwrotator
by Sridhar Ratnakumar 17 Jul '09

17 Jul '09

New submission from Sridhar Ratnakumar <sridharr(a)activestate.com>: The following command runs forever. But then, why would it try external downloads when this package has a tarball on pypi itself? sridharr@whymac:/tmp/fo > bin/easy_install abstract.jwrotator Searching for abstract.jwrotator Reading http://pypi.python.org/simple/abstract.jwrotator/ Reading http://www.abstract.it/svn ---------- messages: 328 nosy: srid priority: bug status: unread title: cannot install abstract.jwrotator _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue81> _______________________________________________

2 1

py2exe - COM Server DLL can't be referenced by VB6 or VS2003
by J.D. Main 17 Jul '09

17 Jul '09

Hi Guys, Hopefully this is the place to ask this question. I have written a COM server with a few trivial string methods to test the integration of Python and VB (and Visual Studio). I have run it through py2exe and created a DLL that actually does register and Windows seems to be happy with it. I can access the methods of this COM object with Python and VBA and, sure enough, it works. That's awesome. However, it can not be added as a reference to a VB6 or a VS2003 project. Both say it's not a valid DLL and it doesn't show up in any of their "reference object" lists. That basically means it's not available for use in that environment. In addition, any sort of code completion or call tips will never function. So my question is this: is there some special interface vodoo that needs to be put in my code or my py2exe setup in order to get this COM server truly visible and accessible within VB6 or Visual Studio? Also, is there even more interface stuff so the code completion/call-tips stuff works? I would love to hear about any experience you may have with all this. Best Regards, J.D.

2 4

PEP 376 - from PyPM's point of view
by Sridhar Ratnakumar 16 Jul '09

16 Jul '09

Here are my comments regarding PEP 376 with respect to PyPM (the Python package manager being developd at ActiveState) Multiple versions: I understand that the PEP does not support installation (thus uninstallation) of multiple versions of the same package. Should this be explicitly mentioned in the PEP -- as `get_distribution` API accepts only `name` argument, and not a `version` argument? > get_distribution(name) -> Distribution or None. >Scans all elements in sys.path and looks for all directories ending > with .egg-info. Returns a Distribution corresponding to the .egg-info > directory that contains a PKG-INFO that matches name for the name > metadata. >Notice that there should be at most one result. The first result > founded is returned. If the directory is not found, returns None. Some packages have package names with mixed case. Example: ConfigObj .. as registered in setup.py. However, other packages such as turbogears specifies "configobj" (lowercase) in their install_requires. Is `get_distribution(name)` supposed to handle mixed cases? Will it match both 'ConfigObj' and 'configobj'? > get_installed_files(local=False) -> iterator of (path, md5, size) Will this also return the directories /created/ during the installation? For example, will it also contain the entry "docutils" .. along with "docutils/__init__.py"? If not, how is the installer (pip, pypm, etc..) supposed to know which directories to remove (docutils/) and which directories not to remove (site-packages/, bin/, etc..)? > The new version of PEP 345 (XXX work in progress) extends the Metadata > standard and fullfills the requirements described in PEP 262, like the > REQUIRES section. Can you tell more about this? I see that PEP 262 allows both distributions names ('docutils') and modules/packages ('roman.py') in the 'Requires:' section. Is this how the new PEP is going to adhere to? Or, is it going to adhere to PEP 345's way of allowing *only* modules/packages? In practice, I noticed that packages usually specify distribution names in their 'Requires:' file (or install_requires.txt in the case of setuptools). Hence, PyPM *assumes* the install requirements to be distribution name. But then .. most distributions have the same name as their primary module/package. Ok, so PEP 345 also specifies the 'Provides:' header. Does easy_install/pip make use 'Provides:' at all when resolving dependencies? For example, does 'pip install sphinx' go look for all distributions that 'provides' the 'docutils' provision.. or does it simply get the distribution named 'docutils'? -srid

12 22

Re: [Distutils] Not installing the install_requires
by P.J. Eby 16 Jul '09

16 Jul '09

At 07:43 AM 7/15/2009 -0700, Peter Bengtsson wrote: >Crap! >That didn't work either! >IOError: [Errno 20] Not a directory: '/home/peterbe/virtualenvs/ >djangopeoplenet/lib/python2.5/site-packages/premailer-1.2-py2.5.egg/ >premailer/version.txt' > >This must be because of some egg magic that I don't understand. >What I did was this (in premailer.py): > >__version__ = open(os.path.join(os.path.dirname(__file__), >'version.txt') > ).read().strip() from pkg_resources import resource_string __version__ = resource_string(__name__, 'version.txt').strip() Make sure that you either list 'version.txt' in your setup() data_files or else use include_package_data=True and a revision control system that includes the version.txt file, or else the version.txt won't be included in your sdists and eggs.

4 3

Re: [Distutils] Announcing the 'Distribute' project
by Lennart Regebro 16 Jul '09

16 Jul '09

Tarek Ziadé: > We have started a new project called 'Distribute'. OK, I will retire my Python 3 branch, and make a branch here instead, within a week. Maybe during the weekend, although I'm fairly busy at the moment. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

2 1

Re: [Distutils] [Python-Dev] PEP 376 - from PyPM's point of view
by P.J. Eby 15 Jul '09

15 Jul '09

At 04:59 PM 7/15/2009 +0100, Paul Moore wrote: >- Virtualenv isn't a workaround (I don't know virtualenv, I'll take >your word for it) It's not one for system package maintainers because it would effectively be managing multiple instances of 'python'. Really not a suitable solution. >- I do not believe that it's clear that sanctioning the setuptools >workaround as the "right" approach by building it into the Python >core/stdlib is the right thing to do. I still don't understand how we're doing that.

4 3

dependency graph of all packages in pypi
by Sridhar Ratnakumar 15 Jul '09

15 Jul '09

The following file gives the list of all packages in PyPI and their 'install_requires' (or 'requires'). http://files.getdropbox.com/u/87045/x/pypi-dependency.txt This list does not include (most of the) packages that have external downloads. -srid

1 0