Re: [Distutils] setup.cfg new format proposal
At 10:13 PM 9/16/2009 -0400, David Lyon wrote: On Wed, 16 Sep 2009 22:01:20 -0400, P.J. Eby p...@telecommunity.com wrote: It's not the application's business what the installation directory is; Yes, but it very much is. An application needs to know what directory it has been installed in and where it can find configuration files and so forth. It appears I was unclear: it is not the application's business to *decide* what the installation directory is. nor is it something that should be specified in setup.py or setup.cfg, as that is 100% the user's business to choose, and the platform tools to supply a default for. Well, it certainly doesn't work that way at the moment. Eh? It's *possible* to specify it in those places now, but well-behaved packages never do. I suspect there is some confusion here; I'm precisely suggesting that we not invent a new, general wheel if we can address the real use cases with a slight adjustment to something we already have (e.g. the extras syntax). Yes, there's much confusion. That's the problem, in addition to many annoying limitations and shortcomings. So if you want to go ahead and describe what needs to be done in\ nice simple easy to understand terms it would benefit everyone. If platform/pyver-specific dependencies are all that's required, there's a way to specify them using setuptools' existing dependency syntax, using extras. install_requires is allowed to have sections that express additional requirements (aka extras) that can optionally be installed along with the base package. Each extra links an option name (e.g. pdf-support) to one or more additional dependencies (e.g. reportlab1.2). In current versions of setuptools-based installers (such as pip, easy_install, buildout, etc.), these extras must be explicitly specified in a requirement, in order to install them. For example, easy_install foo[pdf-support,png-support] to install foo along with whatever requirements are needed for PDF and PNG support. However, if a syntax for extra names were devised, one could implicitly specify extras like 'python-lt-2.6' to be automatically installed when the conditions are met. In other words, there's already a framework for actually *implementing* conditional dependencies, it just needs to have a convention for naming of extras to allow it to work. And in the absence of tool support, it could even be implemented manually, by adding the necessary extra names on the command line of existing installation tools. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup.cfg new format proposal
At 12:41 PM 9/17/2009 +0200, Tarek Ziadé wrote: Also, if I understand clearly the idea, I find it rather cryptic to add conditions to each dependency like what Sridhar has shown. That's actually not how it would work; you simply put section headings inside the extras_require field, rather than having multiple sections in setup.cfg. Then, the static metadata is just the existing PKG-INFO format. Setuptools already supports section headings in extras_require, it just doesn't (yet) automatically install the contents of those sections based on platform/python version; you'd have to explicitly request easy_install somepackage[platform.win32,pyver-2.6] at the moment. But adding automatic defaulting of those flags would be pretty trivial, once their format was officially defined. See http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies for more details. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout + namespace packages + Django management commands?
At 01:48 PM 9/19/2009 +0100, Kyle MacFarlane wrote: The way setuptools (and thus buildout) does namespace packages doesn't work with how Django looks for management commands. Django only looks in the first package in the namespace on the system path and ignores the rest. If they use the package's __path__ attribute, they'll find its contents, whether someone is using pkgutil.extend_path, .pth files, or setuptools. They don't have to support setuptools to support namespace packages, just pay attention to the __path__ variable that's part of standard Python. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout + namespace packages + Django management commands?
At 09:17 AM 9/20/2009 +0100, Kyle MacFarlane wrote: 2009/9/19 P.J. Eby p...@telecommunity.com If they use the package's __path__ attribute, they'll find its contents, whether someone is using pkgutil.extend_path, .pth files, or setuptools. Â They don't have to support setuptools to support namespace packages, just pay attention to the __path__ variable that's part of standard Python. I was hoping more if anybody knew a recipe to get round my problem but I had a look inside Django to see how it looks through packages. The problem is caused by line 58 at this link raising an ImportError: http://code.djangoproject.com/browser/django/trunk/django/core/management/__init__.py It doesn't matter what order find_module is called on various paths, it still relies entirely on the order in sys.path. Calling find_module on second_app before first_app will still fail if first_app is the first app on sys.path (which suggests that something has been done wrong even before line 58 or find_module itself doesn't support namespaces?). Unfortunately I've never dealt with the imp module before. What would I need to do? Import the package (which is actually path in this code), get __path__ from it and then do find_module again but with __path__ instead? Basically, yeah, only it has to happen inside the while parts loop. The downside, of course, is that you'll be importing every application and its management package. It's too bad, really, they could've saved a ton of code and complexity there (as well as being able to support namespace packages, zipfiles, etc.) if they'd just used pkg_resources and entry points. Projects could just declare their commands without needing a management.commands subpackage, or separate modules for each command. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup.cfg new format proposal
At 10:26 PM 9/20/2009 -0400, David Lyon wrote: Eh? It's *possible* to specify it in those places now, but well-behaved packages never do. Not on windows, outside of the c:\pythonXY directory. Create a setup.cfg with an [install] section and you can make it install wherever you tell it to... when installing using setup.py. (bdist_wininst and bdist_msi are something else altogether.) Define well behaved.. If you are saying that Python observes all microsofts recommendations under windows and is well-behaved I think I'd have some comments about that. Well behaved is installing a python program to Program Files but distutils doesn't allow this to my knowledge. It most certainly does; but not in a bdist_wininst or bdist_msi (AFAIK), and definitely not by default. You'd need to specify the location on the command line. If platform/pyver-specific dependencies are all that's required, there's a way to specify them using setuptools' existing dependency syntax, using extras. But you have told everybody that setuptools is dead... and you don't have any plans to work on it any more.. You are misrepresenting my statements. I have neither called it dead nor have I said I don't have plans to work on it any more. (In fact, I've said the opposite, noting that the existence of Distribute makes the possibility of doing some advanced work on setuptools *more* likely, because I needn't worry so much about the maintenance backlog.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Comments on Python 3 support for Distribute.
At 10:15 PM 9/21/2009 +0200, Lennart Regebro wrote: 2009/9/21 Wolfgang Schnerring w...@gocept.com: My favourite colour: use 2to3 as the prefix (consistency helps, I think), like so: 2to3_enabled, 2to3_convert_doctests, 2to3_fixers, ... That works. Maybe just 2to3_doctests? Really? I would think 2to3_anything is not a valid keyword argument name. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 03:49 PM 10/3/2009 +0200, Tarek Ziadé wrote: Notice that this has been fixed in Ubuntu already with a patched version of setuptools Is the patch or an equivalent already in the setuptools tracker? And if not, can someone please post it there? Thanks. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 07:25 AM 10/5/2009 -0700, K. Richard Pixley wrote: How do I delete a package using easy_install? http://peak.telecommunity.com/DevCenter/EasyInstall#uninstalling-packages ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 04:57 PM 10/5/2009 +0200, Lennart Regebro wrote: 2009/10/5 Barry Warsaw ba...@python.org: I apologize for my part in this, but moving forward I think that if it's possible to patch and release a setuptools that works with Python 2.6.3 /and/ earlier Python 2.6.x's, then that should happen asap. PJE seems interested in this, as he asked about a patch, so maybe. I expect to have a small amount of time later this week to work on setuptools. No guarantees, but this is certainly one of the bugs on my short list for doing something with. If that's not possible, then we might need to revert the distutils change in a quick Python 2.6.4. That would be a big mistake. Actually, I think the mistake here is where non-bugfix code was ported from 3.x back to the 2.6.x maintenance branch. I'm particularly concerned about the .compiler / ._compiler change, as it seems to me to be responsible for breaking mingw32 compilation on Windows, but I haven't had time to investigate thoroughly. (It actually looks like a problem that might be in Python 3 as well.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 06:53 PM 10/5/2009 +0200, Lennart Regebro wrote: Possibly if you somehow think it's the Distribute teams fault that a bugfix in Python ended up breaking setuptools. If it would have been better not to fix that bug, then the blame reasonably goes to the Python core developers, not the Distribute team. In this case, though, the Python core developer is also the Distribute lead. (i.e., it was Tarek who made the changes to the distutils.) So it's a bit understandable that some people might wonder if there was a conflict of interest. I don't personally think that's the case; it's pretty much inevitable that the distutils making progress means other things will break. But it's easy to see how others might take the situation another way, or treat it as an example of Distribute policy towards backward compatibility, or of what kind of breakage is considered acceptable in a dot release. It would be good to bear in mind that extending the distutils (or setuptools) is *not* monkeypatching; both libraries provide explicit assurance that subclassing is in fact allowed. And there's nothing all that special about setuptools' subclassing of build_ext; in fact, if you look back in the archives here, other people have done equivalent subclassing to support dynamic library building. I haven't checked their code, but there is a strong possibility that it would also fail in the same way. This is not really about monkeypatching, or about special support for setuptools. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 07:53 PM 10/5/2009 +0200, Hanno Schlichting wrote: If I understand the comments on this ticket correctly, Tarek has changed distutils in a way so the last setuptools release continues to work, correct? Yes. And a very nice fix, done quite quickly. Thank you Tarek. So based on the current state of Python 2.6.4 will work again with an unmodified setuptools 0.6c9? AFAICT, that is correct. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 11:29 AM 10/5/2009 -0700, K. Richard Pixley wrote: P.J. Eby wrote: At 07:25 AM 10/5/2009 -0700, K. Richard Pixley wrote: How do I delete a package using easy_install? http://peak.telecommunity.com/DevCenter/EasyInstall#uninstalling-packages That doesn't remove a package. It simply removes the package from the search path by one method in hopes that no further instances of it will be loaded. To actually remove it, you have to know the format of the library, the package formats, local library storage conventions, and you need to be an expert user of distutils, setuptools, buildout, etc, in order to determine the content of the package itself in order to remove it manually. As it says at the above link: After you've done this, you can safely delete the .egg files or directories, along with any scripts you wish to remove. What it doesn't mention (but which should be apparent if you actually run the command) is that it will output the locations of the .egg files or directories and scripts in question, allowing you to copy and paste them to 'rm' or 'del' commands. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
At 09:20 AM 10/6/2009 +0300, Alex Grönholm wrote: P.J. Eby kirjoitti: At 11:53 AM 10/5/2009 +0200, Lennart Regebro wrote: 2009/10/5 Jeff Rush j...@taupro.com: Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major. Well this major... It's a bug fix that breaks a setuptools monkey-patch. Subclassing distutils commands != monkeypatching. If, say, numpy's distutils extensions subclass build_ext and override that method, they could have had the same problem. Same for anybody else's distutils extensions. Setuptools subclasses distutils commands and then replaces the original classes with its own. Example from setuptools/__init__.py: import distutils.core distutils.core.Command = Command Isn't this exactly what monkey patching means? Yes, but that's got nothing to do with the bug that's been being discussed. The same change bit pywin32, and it doesn't use setuptools at all. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Setuptools 0.6c10 release imminent; please test
I've just updated the setuptools trunk and branch with a large number of bug fixes, preparing to release 0.6c10. These fixes include fixes for all the setuptools bugs currently marked in-progress or testing on the setuptools bug tracker as of this moment, and I'd like your help in ensuring that the new version is ready for release. Major updates and fixes include: * Fix for Vista UAC errors running easy_install.exe or other installer-looking executables * Fix for errors launching 64-bit Windows Python * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Support for SVN 1.6 * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered site directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious already imported from another path warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg * Fixed running the test command under Python 2.6+ (0.7a1 trunk only) Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious already imported warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==dev (for the 0.7a1 trunk) or setuptools==dev06 (for the 0.6c10 development branch). But before you do that, be sure to uninstall Distribute completely. In particular, please note that these changes are NOT a merge from Distribute; upon review, many of the tracker-submitted patches used as a basis for forking were incorrect, incomplete, introduced new bugs, or were not addressing the root causes. (E.g., one of the changes I made fixes three superficially unrelated issues in the setuptools bug tracker.) Even if some of the change descriptions are the same in Distribute, many of the fixes are implemented quite differently. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the virtualenv-distribute mess
At 08:09 AM 10/12/2009 +, Reinout van Rees wrote: OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist I'm pretty grumpy right now. Relax, take a deep breath, and then easy_install setuptools==dev or setuptools==dev06. ;-) It turned out to be easier than I expected to clean up pretty much all the outstanding (i.e. in the tracker) bugs this weekend, although that was mainly due to avoiding overhead by reading all the bugs together and making the changes more-or-less simultaneously. In this case, it was prompted mainly by the unfortunate, policy-breaking change to Python 2.6.3, but I'm thinking that maybe a quarterly Bug Weekend and subsequent maintenance release for setuptools might not be a bad thing. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.6c10 release imminent; please test
At 07:28 PM 10/12/2009 -0400, sstein...@gmail.com wrote: we must uninstall Distribute completely get these fixes. That's Distribute's doing, not mine. As I understand it, their package includes a 'setuptools' package, and if it's on your sys.path, then installing the new version of setuptools will be a no-op. If they hadn't done that, there'd be no problem. See the Distribute documentation. In any case, the update is not intended for people who are happy to have Distribute, but the people who are unhappy about having to switch, or deal with its workarounds... or just wish the whole discussion would go away. Then suddenly out of the blue It may appear sudden to you, if you haven't been reading Python-Dev. There's been quite a bit of discussion about an urgent bug that Tarek introduced in Python 2.6.3. It's mainly because of that bug that I took the time to go ahead and get a bunch of other pending bugs cleaned up and checked in. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] why would you ever need to specify setuptools as a dependency?
At 01:31 PM 10/13/2009 -0400, Tres Seaver wrote: Why? Because the user might have, say, setuptools 0.6c8, and the package relies on a bugfix in 0.6c9. Also, at some point, there will be an 0.7a1, with new features that some people might actually want to use. (Some projects also actually use setuptools or easy_install at runtime, not just pkg_resources; e.g. buildout, pip, etc.) Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute. Nobody except system packagers, who would otherwise have to troll the source for pkg_resources imports and such. (Even then, a project could declare entry points in its setup.py that will get called by some other project, without ever directly using a pkg_resources or setuptools API.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] dev versions
At 01:45 PM 10/13/2009 -0400, Tres Seaver wrote: Reinout van Rees wrote: On 2009-10-08, Ian Bicking i...@colorstudy.com wrote: So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec. 0.3.1-anything will sort after 0.3.1 and before 0.3.2dev, so that's probably what you want. Typically, the anything would be a revision number or date tag (e.g r5143 or 20091005), but it could also be a manually-assigned sequential number. Technically, this is a post-release tag, and in the previous proposal for a restricted version format, you would designate it with 0.3.1.post. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute and buildout: best practices?
At 02:51 PM 10/13/2009 -0400, Jim Fulton wrote: Really the run-time code needed to support namespace packages should be split out into a separate package and eventually added to the standard library. Are you volunteering? ;-) Seriously, MvL's namespace package PEP (#382) already takes care of most everything that's needed. With it in place, the only advantage of setuptools' approach is the ability to add more items to a package __path__ after it's already imported. (i.e., the fixup feature.) I heartily approve of that PEP, in case it's not obvious. I'd love to see it in Python 2.7, and will happily add support for it in setuptools 0.7. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [buildout] RFC: buildout support for distribute
At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote: Notice that the current trunk of Distribute is now changing any 'setuptools' requirement that is tiggered using Requirement.parse and resolve APIs into a 'distribute' one. Please note that this change will cause problems for people in the future, as new features are introduced in the 0.7a1 line. The earlier version of this hack, which only ignored requests for older versions of setuptools, would not have caused such a problem. I would suggest that Distribute should only silently ignore requests for versions of setuptools that it can explicitly emulate; other requests should result in an error, so that a problem cannot pass silently. Otherwise, a package depending on new features in the 0.7 line will silently fail when those features are not present in its operating environment. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [buildout] RFC: buildout support for distribute
At 09:53 PM 10/13/2009 +0200, Tarek Ziadé wrote: 2009/10/13 P.J. Eby p...@telecommunity.com: At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote: Notice that the current trunk of Distribute is now changing any 'setuptools' requirement that is tiggered using Requirement.parse and resolve APIs into a 'distribute' one. Please note that this change will cause problems for people in the future, as new features are introduced in the 0.7a1 line. The earlier version of this hack, which only ignored requests for older versions of setuptools, would not have caused such a problem. I would suggest that Distribute should only silently ignore requests for versions of setuptools that it can explicitly emulate; other requests should result in an error, so that a problem cannot pass silently. Otherwise, a package depending on new features in the 0.7 line will silently fail when those features are not present in its operating environment. Ok sure, makes sense. We will return 'distribute' only if 'setuptools' is from the 0.6.x series and below. Great. I assume that means you plan to incorporate any further bug fixes that land in 0.6c10 (or, gods forbid, c11) in the release where this change is made. For versions you don't support emulating, I strongly suggest adding an error of some kind, since actually *installing* setuptools with Distribute still present on sys.path would cause a problem. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Future namespace support
At 06:46 PM 10/14/2009 +0200, kiorky wrote: As i understood, NS.foo from setuptools can't be imported in NS.bar from pkgutil and vice versa. Not so. The true implementation of nsp's is in __path__, which is provided by Python's import libraries, not setuptools or pkgutil. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Future namespace support
At 04:55 PM 10/14/2009 +0200, Lennart Regebro wrote: 2009/10/14 kiorky kio...@cryptelium.net: That's not what said the PEP (IOW what i had understood of) Oh, you don't *use* it the same way, no, but I assumed that the internal mechanisms would be similar. Maybe I was wrong. You can use as many namespace package mechanisms as you want, simultaneously, as long as they're not all being used for the same namespace package. Bear in mind that the true mechanism of nsp's is simply a module's __path__ object; pkgutil and pkg_resources simply provide utilities for setting the __path__ appropriately. With PEP 382, the utilities become unnecessary, except for backward compatibility, and if you want to do fixup of a __path__ when sys.path is changed. However, as long as each nsp is only registered with one such utility, there should be no conflicts. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Proposal for Distribute 0.7
At 02:32 PM 10/15/2009 +0200, Tarek Ziadé wrote: That would make us happy, because we would be able to work and continue if you are not available sometimes without the feeling that we are locked, and that would give you the manpower you miss to develop some of your idea. So... you've explained what part of this proposal will make you happy. Where's the part that will make me happy? Generally speaking, that's how a win-win proposal works. There's a second issue, too. You've repeatedly smeared setuptools on Python-Dev to cover your mistakes, and you have *yet* to retract or amend any of those statements or apologize for them in any of the places where you made them -- despite numerous requests that you do so. In each case where I've made a request, I know you've received the request, because you've replied to the email or comment in which I made it. But in none of your replies have you even *acknowledged* the issue, let alone done anything about it. Instead, you've either changed the venue, the subject, or just launched a new smear. This latest proposal of yours is of course just another such subject and venue change, in reply to one of my more recent requests (via Reddit comment) that you do something about this outstanding issue. But if you were genuinely serious about the things you claim to be interested in, you might have paid attention to such things as my mentions that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). In my book, the mere fact that you haven't asked me who those team members are, or offered to step down in favor of them (either privately OR publicly), tells me everything I need to know about where your real interest in this matter lies. Now, don't get me wrong - I'm not blacklisting you or refusing to support you. You are no less a user of setuptools than any other, after all. To the extent that you are courteous in your requests regarding setuptools, you will get reasonably courteous responses from me, as has been the case on Python-Dev and here in the last few days. (And for that matter, all along!) But please don't bother floating any more proposals for some sort of direct collaboration or co-operation between you and I, not now, or ever again, until such time as you have shown as consistent a track record of behaving with integrity, as you've shown a *lack of* in your interactions with me. Because as of right now, I can't trust you enough to work with you. I can't trust you not to blame every mistake you make on me, and then say, oh let's just forget about everything when you're called on it. I can't trust you to admit when you don't know something (see our recent Catalog-SIG exchange), or to not throw my agreement to work with you back in my face the first time we disagree on something. And these things alone would be more than enough reason not to work on a software project with someone. But at this point, I can't even trust you to not immediately follow up my mere *agreement* to work with you, with a blog post like PJE finally comes to his senses or some such rubbish. Your political gaming behavior is a deal-breaker for me, and it's not something that any behavior you do *now* can fix. I've tried for months to give you the benefit of the doubt, the benefit of the language barrier, and maybe even the benefit of a complete lack of sensitivity or clue on your part. And, most recently, you've had no fewer than *five* extra chances from me to act with integrity, but you've chosen to showboat instead. Every. Single. Time. So, good luck with that, 'cause I'm done with it. To the rest of the Distribute team: I have absolutely no quarrel with any of you, as far as I know, and I remain open to an (off-list) discussion on any topics or win-win proposals you'd like to discuss. P.S. Tarek: if your next move is to issue a series of halfhearted, backhanded retractions so you can whine that you did what I asked and I still won't work with you, please don't bother. It's not really credible evidence of your integrity at this point, so I'm done with asking you for anything. IOW, this is *not* a sixth request for a retraction, it's the termination of my many, many attempts to deal with you in good faith. P.P.S. Everyone else: please don't clog the SIG mailing list with further discussion on this topic. If you feel the need to flame me for some reason, please show more consideration to the group than Tarek has, by sending it to me in private, or go rant on your blog or twitter if your need for attention is too great. In return, I will guarantee this to be my last mailing list post on this subject. (I guarantee that I'm at *least* as tired of it as you are.) Thanks in advance. ___ Distutils-SIG maillist -
Re: [Distutils] Proposal for Distribute 0.7
At 02:38 PM 10/15/2009 -0400, sstein...@gmail.com wrote: that there are other people on the Distribute team who I'd seriously consider as committers on setuptools or even as a chief maintainer of the setuptools 0.6 line (if not more). ...asked me who those team members are I'm asking. Who are they and, if you are willing to give them access, have you offered it and they've declined, or you were waiting until...what? You had Tarek's acknowledgement or permission? I am not trying to poach anyone or stir up trouble, which is why I've taken a very passive public stance on the issue -- although it has included me naming names in certain venues, including here. However, I *am* in private contact with more than one member of the Distribute team, each of whom first contacted me. In order to avoid creating any further drama here or in the Distribute team, I will leave it up to them to make any public statements, when/if they choose to confer with their colleagues on the matter. (I would prefer, of course, a joint statement at the appropriate time.) I wish that such complications weren't necessary. If cooler heads had prevailed in July, this could have and likely would have been resolved back then. We, regular Python users, have been asking for you to let someone help with setuptools for years since you obviously have other priorities and the various issues in setuptools have affected many of us in various ways. The only reason I've done an 0.6c10 is because of a policy-breaking change to Python that breaks setuptools users, and that can't be worked around with configuration, command-line options, or other tweaking of the runtime environment -- as was able to be done with approximately 9 out of 10 of the setuptools bugs in the tracker. If it weren't for that, I'd have been more-or-less happy to let Distribute become the quasi-official replacement for setuptools 0.6, despite my annoyance at some of the public comments made by its promoter(s) prior to the 2.6.3 issue. Indeed, as previously stated, I even tried to arrange a handoff of 0.6, wherein the changes made in Distribute would've been released as 0.6c10 or 0.6final back in July... and public talks broke down due to certain persons' flaming and posturing. That's one reason I'm only doing off-list talks now -- less chance of random jerks inserting themselves into the middle of the discussion, making me think they're part of Distribute and that their comments reflect Distribute policy (as also happened back in July). Also, no need for persons on either side to put up any posture or spin, when there's no audience to play to. Are you really willing to let anyone help? Really? Indeed. There's a list, and some of them obviously have time to work on Distribute, so it's not a matter of me only picking people who don't have any time, as Tarek and others have more than once accused me of. Do it, then, Discussions are ongoing. Also, I've made it pretty plain for a long time that if Ian Bicking or Jim Fulton were ever willing to take it over, I'd hand it *all* over -- 0.7 as well as 0.6 -- and happily retire from the distribution tools business. I trust their vision as architects, and their track record of supporting their users IMO speaks for itself. Both are past contributors of non-trivial features to setuptools, as well as accomplished installation tool developers in their own right. It would be a joy and an honor to turn the keys over to either one of them, either as an individual or as the leader of a new team. (I would love to see some of pip and buildout's features integrated in setuptools 0.7, for example.) (Ian, btw, already has PyPI maintainer rights to setuptools, and Jim already has commit rights to setuptools SVN... giving further lie to the idea that I'm not willing to give people access or let them help.) That having been said, there are definitely other people I'd give varying degrees of access to, just not at the here, take it, please, I want you to have it! level I would grant to Ian or Jim. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Proposal for Distribute 0.7
At 10:46 AM 10/16/2009 -0400, sstein...@gmail.com wrote: I don't know that I'd call what I saw designed. Complex, yes, but design implies a plan and known direction, communicated by design documents with tests that prove the code is working as expected. This is not designed by any objective standard I'd use. You are correct; setuptools itself was not particularly designed. Eggs are, entry points are, a few other odds and ends were designed, but setuptools itself (and *especially* easy_install) are a collection of hacks upon hacks, mostly done in a rush to get something out the door... which as soon as it became popular, locked into a cycle of not having enough time to do improvements, because maintenance was taking so much time. Maybe PJE is some sort of savant who can keep the myriad details of a piece of code like this in his head Nope. Why do you think I've not been thrilled about working on it? ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] setuptools 0.6c10 delayed until Monday
After giving it some thought, I've decided to hold off on pushing out the 0.6c10 release until Monday morning, since it's likely that some people have scripts or build processes that run off of ez_setup SVN or the latest PyPI version of setuptools... and who aren't aware the release is coming and might be surprised by it. It would therefore probably not be a good idea to push this out on a Friday. Also, this will give those who are using Distribute and do *not* wish to use this release, a chance to upgrade to the latest version of Distribute first. (Which, if I understand correctly, includes code to prevent accidental re-installation of setuptools.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools 0.6c10 delayed until Monday
At 02:03 AM 10/17/2009 +, Reinout van Rees wrote: I added the code that checks whether we're not requesting a 0.7-series setuptools. So if a 0.7a1 setuptools comes out and someone requires it, it will be installed: distribute won't fake a 0.7. And I added a similar check in the (from the top of my head) on_insert() method that raises an error if you try to install a 0.7 setuptools inside a distribute-handled working set (like you suggested, iirc). Yep. Thanks! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Setuptools 0.6c10 released
The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Fix for Vista UAC errors running easy_install.exe or other installer-looking executables * Fix for errors launching 64-bit Windows Python * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered site directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious already imported from another path warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious already imported warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==0.6c10. (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any problems with setuptools to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buglet in setuptools 0.6c10
At 03:33 PM 10/19/2009 -0400, Barry Warsaw wrote: Sorry for the lame-ass bug report, but my stack is really deep and I didn't want this one to go unreported. I just tried 0.6c10 to see if it would fix a problem I'm having. How fortunate that it hit Cheeseshop at just the right time ;). Unfortunately, there's a bug in setuptools/command/sdist.py Line 184 references string.join, but 'string' is undefined. -Barry Thanks; it's fixed and pushed back to PyPI. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.6c10 released
At 11:33 PM 10/19/2009 +0300, Alex Grönholm wrote: P.J. Eby kirjoitti: The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Fix for Vista UAC errors running easy_install.exe or other installer-looking executables * Fix for errors launching 64-bit Windows Python According to the notice on the setuptools bug tracker, you did this by avoiding the use of LoadLibraryEx(). I don't see any changes in launcher.c in setuptools SVN yet, did you forget to commit? It looks like I managed to revert it in my working copy, too. Crap. (Which is weird, because I know I built the executables before and tested them on a 64-bit Vista box.) I've reapplied the changes and put it back in SVN. 'easy_install setuptools==dev06' will let you get it for now. Or am I looking in the wrong place? I'd like to see your solution. I changed the loadable_exe() function to be a no-op string copy, essentially. Looks like I'll need to go ahead and put out a c11 tomorrow. Sorry about that. Thanks for the prompt report. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Avoid dependency_links / find_links
At 12:02 AM 10/20/2009 +0200, Patrice Neff wrote: So the question would be: is there any way to avoid following any dependency_links and/or find_links paths and only use the index_url? Yes. See: http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts which explains how to use the command line or configuration files to control this. Also see: http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options under the '--allow-hosts' option for more details on the syntax. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buglet in setuptools 0.6c10
At 02:05 AM 10/20/2009 +0100, Matthew Wilkes wrote: On 2009-10-19, at 2055, P.J. Eby wrote: Thanks; it's fixed and pushed back to PyPI. With the same version number. What about the people who have already installed your broke 0.6c10 that don't read this list? They'll see an announcement for 0.6c11 tomorrow. I didn't want to bump the version number right away, in case there were any other problems. (And there were.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] First attempt: close but no data files!
At 05:47 PM 10/22/2009 -0700, Kaelin Colclasure wrote: Greetings, I am attempting my first Python contribution and have run into a speed bump getting a working setup.py using setuptools. Specifically, I cannot coax it to install my package data files into the site-packages directory. Here is a link to my project where my setup.py is available for browsing: http://bitbucket.org/kaelin/cuttlefish/ There's no setup.py there. S close! TIA, -- Kaelin ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] First attempt: close but no data files!
At 09:58 PM 10/22/2009 -0700, Kaelin Colclasure wrote: Restructuring as a package did indeed get things working as expected. It's somewhat unfortunate that this is a requirement, as it made for a lot of noise in my Mercurial repository and now most of my code is in a module with the unhelpful name __init__.py Given how short your data file is, the fact that it's entirely text, and the fact that your module script always needs it to be loaded, I wonder why you don't just make it a string constant in the .py file to start with, or better yet, simply directly create the data structure it represents. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] First attempt: close but no data files!
At 08:53 AM 10/23/2009 -0700, Kaelin Colclasure wrote: On Oct 23, 2009, at 8:16 AM, P.J. Eby wrote: At 09:58 PM 10/22/2009 -0700, Kaelin Colclasure wrote: Restructuring as a package did indeed get things working as expected. It's somewhat unfortunate that this is a requirement, as it made for a lot of noise in my Mercurial repository and now most of my code is in a module with the unhelpful name __init__.py Given how short your data file is, the fact that it's entirely text, and the fact that your module script always needs it to be loaded, I wonder why you don't just make it a string constant in the .py file to start with, or better yet, simply directly create the data structure it represents. I think you're referring to cuttlefish-config.plist, which is intended to be edited after installation to refer to the particulars of the installed site's filesystem, etc. Don't do that. Package data is for static, read-only data used by a library or application at runtime. [And yes, I realize having such a config file live inside the package is sub-optimal. I'm just looking for a low-impedence solution that works with the PyPI infrastructure. That said, if there are best practices for such things established and supported by setuptools I'm all ears ] Put it with documentation, or use the standard distutils data_files option, rather than package data. User editable files should *not* be installed adjacent to the code; it's rightly frowned on by Linux distributions and system administrators everywhere. If the issue is that it's a global configuration file and you don't know where else to put it, base the location on the user's home directory (on *nix ) or an APP_DATA subdirectory (on Windows). If it's not a single per-user location, then use an environment variable or command-line option (for command-line tools) or as an argument (for Python APIs). Some tools also ship with a lot of package data as *templates* for user-configurable stuff, and include a short script to copy the template to a user-specified location, possibly filling in a few things specified on the command line, or via interactive prompts. This is a good way to provide a nice UI for your installation/setup, especially in the case where someone might need multiple copies of the configured data (e.g. a webapp you can install multiple instances of, like Trac). There is also a 'static/' directory with a bunch of webapp resources in it. If those are user-editable, it's probably a good idea to include a script that copies and/or customizes them and places them in a user-defined location, rather than having the code read them directly from the package (and thus requiring the user to edit them directly). Of course, if those webapp resources are *not* user-editable, then leaving them in your package data is fine. And it is now installing with the package perfectly too. Thanks again for the helpful guidance! You can thank me (and make a lot of sysadmins happier, or at least a little less grumpy) by not locating any user-editable files inside your package directory. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [issue89] easy_install silently drop symlinks when auto-extracting tarball source distributions
At 12:01 AM 11/2/2009 +0100, Martin v. Löwis wrote: It's actually Jeff Rush who is in charge of this tracker instance. I can't change the setup without him agreeing. So, Jeff, where else should the roundup instance for setuptools send its notifications? In over 1 year, there are now a grand total of 89 such messages (at most) that have been sent to the list, vs. 5 messages just sent now (6 when you count this one) discussing whether or not they should continue to be sent here. So far, there has also only been one complaint or request to change this, as far as I'm aware. (Personally, I like them just fine where they are. Among other things it makes it easy for someone to answer the ticket via email, which is one of the reasons I asked for it to be set up this way in the first place.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling Distribute
At 11:00 PM 11/5/2009 +, Ram Rachum wrote: Lennart Regebro regebro at gmail.com writes: 2009/11/5 Ram Rachum cool-rr at cool-rr.com: Why only if there's C code? Because in general you want to compile the code on the system when it's Linux or osx etc. It works better, and you don't have to provide both 32bit and 64 bit versions and yadayada. I personally find it more convenient to install binaries than from source. Why? Because it requires less work on the user's side. Not for people using easy_install or its derivatives (like pip and buildout). easy_install-based tools work as easily with source as binaries. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] People want CPAN :-)
At 03:57 PM 11/7/2009 +0100, Andreas Jung wrote: - supports too much different versioning schemas. Both schema supported by setuptools and the one proposed by Tarek in some PEP are totally over-engineered. A simple and *enforced* versioning schema is what I want to see. - no more external hosting of packages. If people want their packages listed on Pypi, they should be required to upload their packages on PyPI (no more issues with non-available external server, no more issues with mirroring external servers, no more issues with wrong download URLs within package metadata) Do note that at least these two requirements of yours are likely to be opposed by some with at least as much force (if not more so) than you are proposing them with. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] People want CPAN
At 03:13 PM 11/11/2009 +0100, Tarek Ziadé wrote: But you call it with install in your example, meaning that is is called at install time, right ? Or it is just that you want to get the --prefix value finalized and computed by the install command. If it's the later, I guess you will be able to use the upcoming sysconfig module, that gives you the install schemes, depending on sys.prefix/sys.exec_prefix. The issue is that setup.py can accept multiple commands on the command line, and in principle build_clib might be being called as a subcommand of build (and thus of install). So, he needs the *active* --prefix, either from the command line, config file(s), or defaults. Simply having an API to get the defaults won't help this. Really, getting a finalized install command object is the only way to do this correctly in distutils at the moment, and the sysconfig API won't change that. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Improving distutils vs redesigning it (was people want CPAN)
At 12:36 AM 11/12/2009 -0600, Robert Kern wrote: Sorry, I edited out the bit at the last minute where I explained that it would be great to have a centralized option-managing object such that any command can ask what options were set on any other regardless of the dependencies between commands. Actually, that such a thing is needed in the first place is evidence of one of the deepest design flaws in the distutils -- the fact that things which are fundamentally system or project-level configuration values are defined in terms of options to commands! The distutils is a definite case of superficial design flaws being so annoying as to keep most people from noticing the fundamental design flaws. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] obtaining easy_install prefix in setup.py
At 02:59 PM 11/18/2009 -0500, Pavol Juhas wrote: Hello, I searched and read the recent discussions on the distutils-sig list and I hope someone can help me with the following problem. Is there a way to recover the prefix value inside pkgfoo/setup.py, when it is installed as easy_install --prefix=value pkgfoo (pkgfoo is a directory with setup.py) Short of walking the stack in some truly hideous fashion, no. This is something that needs a configure step, and is unlikely to be supportable in setuptools until after distutils has its own configure command. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] obtaining easy_install prefix in setup.py
At 12:59 AM 11/19/2009 -0500, Pavol Juhas wrote: As PJE mentioned, it is indeed possible to walk the stack trace and rip out the original sys.argv (and its '--prefix' element) from the easy_install main. Technically, I meant it's possible to walk back until you find a 'self' that's a different Distribution instance, at which point you can ask for an easy_install command and check for a prefix. You're probably better off doing that than trying to parse argv, especially since the prefix might be coming from a configuration file anyway. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] One package for both python and jython
At 04:40 PM 11/19/2009 +0100, Fabrizio Pollastri wrote: the source structure is the following. my_package_source_dir/ common_files files_for_python files_for_jython It will be a maximum, if distutils let me to reach the following goals. 1. python/jython setup.py sdist command has to build the distribution tar my_package.tar.gz containing all files required by python and by jython. 2. python setup.py install command has to install in the python package tree my_package_source_dir/ common_files files_for_python 3. jython setup.py install command has to install in the jython package tree my_package_source_dir/ common_files files_for_jython It is possible to implement this behavior with the setup function of distutils? As long as the Python and Jython files are distinct packages or distinct top-level modules, you can simply pass different parameters to setup(), based on which platform you're on. (Specifically, changing the 'packages' and 'py_modules' parameters.) (If you have to have different versions of the *same* packages or modules, it's a bit more difficult and the directory layout is more complex, but it can still be done.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386 status - last round here ?
At 07:55 PM 11/26/2009 +, Floris Bruynooghe wrote: On Thu, Nov 26, 2009 at 01:08:34PM +0100, M.-A. Lemburg wrote: Examples: 3.2.0a0.20091125 3.2.0a1 = 3.2.0_alpha_1 Frankly I find this confusing. I'm fine with 'alpha' being a synonym for 'a' but the underscores just confuse things IMHO. They're also not backwards-compatible with the current schemes being used by setuptools and its derivatives (Distribute, pip, buildout, etc.), which interprets underscores differently. (Technically, an underscore should never be in a version, since underscores are used in filenames as an escaped version of a dash.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Common version-comparison semantics for peace love and harmony
At 10:32 AM 11/28/2009 +1100, Ben Finney wrote: This is a red herring, AFAICT. It's been discussed already that workflow is orthogonal to version comparison semantics. That is, nothing about a workflow involving snapshots or dev versions etc. implies that exceptional version keywords need to be accommodated. Exactly the same workflow can take place by choosing different version strings that work with existing version-comparison semantics. Moreover, AIUI there is no injunction that all projects must follow exactly the semantics of PEP 386, right? So why not have a *simple* standard (all version string components compared alphanumerically) in PEP 386, that is known to work unmodified with existing package systems, without Python-specific translation layers for version comparison? For the simple reason that it involves asking one group of people to change how they work -- with no immediate benefit -- so that another group can avoid having to change how they work. Why should developers change, and packagers not? It's simply not an equitable request, which is why the proposal is unrealistic. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Common version-comparison semantics for peace love and harmony
At 12:26 PM 11/28/2009 +1100, Ben Finney wrote: I think you're reading a proposal that I didn't write. Are you not the person who's proposed using simple alphanumeric strings for version comparison? My understanding of PEP 386 is that it *isn't* about asking Python developers to change how they work. Is that not right? Asking them to generate alternative versioning schemes, without the ability to use pre-release versions (e.g. alpha, beta, etc.) would most certainly be a change from the status quo. Moreover, what is a standard for if not for encouraging people to follow it for the benefit of many? Usually, they get something in trade. Supporting WSGI means you get to use WSGI apps, or run on a WSGI server, for example. So, cost and benefit are balanced. In contrast, a popular Python library or app will get packaged if somebody wants it, and not if they don't. There isn't a lot of incentive for a developer to do something different, solely for the sake of the packager... which is probably why things are the way they are now. If, on the other hand, there's some positive benefit being offered (e.g. a new tool that makes life easier for them or perhaps their users), then there might be some incentive to learn a new way of coding versions. But without such an incentive, who wants to learn some new way to encode prerelease versions? This is why I've argued for keeping a scheme in 386 that can mechanically translate most existing versioning schemes found in the wild: it means that most people won't have to do a thing, as tool builders can just use suggest_version(). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Common version-comparison semantics for peace love and harmony
At 10:50 AM 11/28/2009 +0100, Laura Creighton wrote: But I think that it is the other way around ... what we want is a timestamp. The algorithm is for guessing which version is ealier in the absence of a timestamp. You're assuming a process with no branches, where e.g. version 1.2 is being updated while 2.0 is being developed. Timestamps are not a general substitute for versions. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Common version-comparison semantics for peace love and harmony
At 09:41 AM 11/28/2009 +0100, Tarek Ziadé wrote: That's completely wrong, the proposal is a benefit for all of us, because it standardizes something that is already being done. You seem to have misunderstood me; I'm objecting to Ben Finney's simple alphanumeric sort, not to PEP 386 in general. PEP 386 propose a scheme to be adopted by developers or tools, but if some people want to stick with their own internal version scheme for development versions or post/pre release versions, they can do it without any problem. And they don't have to follow any PEP 386 convention for their internal work. This is not actually true, since developers working in a team situation can be sharing and building binary releases of these packages. So you have two choices: - an implicit, heuristic ordering (that's what is happening today) - a explicit, documented ordering. that's the goal of PEP 386. Setuptools' version scheme *is* explicit and documented -- as you should know, since I pointed you to those docs when you were writing PEP 386. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386 status - last round here ?
At 08:11 PM 11/28/2009 +0100, M.-A. Lemburg wrote: Tarek Ziadé wrote: On Thu, Nov 26, 2009 at 1:08 PM, M.-A. Lemburg m...@egenix.com wrote: Here's another take at a minimal change to the format which includes the things we discussed, adds a few more aliases for the post and dev markers and also adds optional underscores for more readability. Please don't add underscores to the syntax -- they will cause problems with the filename escaping and parsing used today by setuptools and compatible tools, and will produce inconsistent comparisons between rational versions and the version schemes supported by setuptools. Ideally, it would be best to keep PEP 386 versions a strict subset of setuptools-supported versions, to minimize migration difficulties. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 386 status - last round here ?
At 09:15 PM 11/29/2009 +0100, Tarek Ziadé wrote: 2009/11/29 P.J. Eby p...@telecommunity.com: [..] WSGI and setuptools have been widely adopted in spite of their technical and ideological flaws, because they had good incentive engineering. Or, in other words, because practicality beats purity, every single time. Do you mean here that this independently-created standard, this good incentive engeneering a.k.a. Setuptools, is doomed not to evolve anymore ? e.g. to adapt its standard to a common standard that is going to raise and be added in stldib at some point ? I'm saying that ignoring backwards compatibility (as MAL and Ben have proposed) is bad incentive engineering. I don't have any disagreement with what you're doing wrt PEP 386, btw; we already had all the technical issue discussion necessary back when you first wrote it. I've just been chiming in on a couple of threads where people have proposed changes that would break backward compatibility and present user experience. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling pkg_resources
At 02:09 PM 11/30/2009 +, Ram Rachum wrote: I've asked before about bundling Distribute. But now I ask, is it possible to pull out the `pkg_resources` module from the Distribute folder and bundle only that with my project? If your project is a standalone application with a completely isolated sys.path, then yes, you can bundle it. If your project is a library or shares sys.path directories with other libraries or applications, then no, *do not bundle it*. (This is true even for the original pkg_resources, but it's doubly true for Distribute's pkg_resources, as installing it may break a setuptools-based installation's ability to upgrade setuptools.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling pkg_resources
At 07:16 PM 11/30/2009 +0200, cool-RR wrote: Well, that sort of sucks. And this is my motivation for bundling the `pkg_resources` from Distribute. The last thing I want is having my software fail for my users because of setuptools while I have Distribute installed locally and can't see the bug on my computer. That's *really* unlikely. Setuptools' runtime functionality (i.e., pkg_resources) has an extremely low bug count. There have actually been more new pkg_resources bugs in Distribute's version of it (due to their changes) than there are outstanding reported bugs in the original pkg_resources. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling pkg_resources
At 08:00 PM 11/30/2009 +0200, cool-RR wrote: On Mon, Nov 30, 2009 at 7:57 PM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 02:09 PM 11/30/2009 +, Ram Rachum wrote: I've asked before about bundling Distribute. But now I ask, is it possible to pull out the `pkg_resources` module from the Distribute folder and bundle only that with my project? If your project is a standalone application with a completely isolated sys.path, then yes, you can bundle it. If your project is a library or shares sys.path directories with other libraries or applications, then no, *do not bundle it*. (This is true even for the original pkg_resources, but it's doubly true for Distribute's pkg_resources, as installing it may break a setuptools-based installation's ability to upgrade setuptools.) What I was thinking is to put it in its own package, and then import it like `from my_package import pkg_resources`. Would that still be problematic? Not if your modules are the only ones using any pkg_resources APIs within a given program. But consider what happens if both your package and another package are calling 'require()' -- just to give a really simple example. You will have two working_set objects that don't agree with each other, or with sys.path. (Similar issues may also apply for other pkg_resources data structures and APIs.) Bundling pkg_resources is really not a good idea for anything but a 100% standalone application or similarly controlled environment, where you know that nothing else will be doing that kind of thing. (Bundling it alongside your setup.py to use during installation -- but not actually installing it -- would also be relatively safe.) If all you're worried about is that a user's version of setuptools might have some sort of bug in pkg_resources, you needn't be. It's the single most stable part of the setuptools code base, both in the senses of infrequently changing and not a lot of bugs. Even if someone's using a version of pkg_resources that's say, 2 or 3 years old, you're not likely to see any bugs more severe than a spurious warning message that something might be being imported from more than one place. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling pkg_resources
At 08:10 PM 11/30/2009 +0100, Tarek Ziadé wrote: 2009/11/30 P.J. Eby p...@telecommunity.com: At 07:16 PM 11/30/2009 +0200, cool-RR wrote: Well, that sort of sucks. And this is my motivation for bundling the `pkg_resources` from Distribute. The last thing I want is having my software fail for my users because of setuptools while I have Distribute installed locally and can't see the bug on my computer. That's *really* unlikely. Setuptools' runtime functionality (i.e., pkg_resources) has an extremely low bug count. There have actually been more new pkg_resources bugs in Distribute's version of it (due to their changes) than there are outstanding reported bugs in the original pkg_resources. As I said earlier, we've had our share of bugs because we needed to make Distribute work in some particular environments, but that was bootstraping issues we've fixed. And if we have more we will fix them and release another version of Distribute. I wasn't criticizing Distribute - I was using Distribute to show just *how low* pkg_resources' bug count is. (You know, this is now the third time in the last few days where you've interpreted my *positive* comments about your work (e.g. PEP 386) to someone else here as being some sort of criticism or argument with you.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling pkg_resources
At 08:10 PM 11/30/2009 +0200, cool-RR wrote: Now I'm confused. If that's true, what reason is there to use Distribute's `pkg_resources` at all? Unless there's some bug they've fixed in it that nobody has reported here or on the setuptools bug tracker, there isn't any. (And of course, if such a bug exists, I would certainly like to know about it.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bundling pkg_resources
At 08:59 PM 11/30/2009 +0200, cool-RR wrote: Okay. But I don't use `require()`, the only thing I need from `pkg_resources` is the ability to extract resources from folders. So will there be any problem if I bundle it for that? If that's all you're using, probably not. In any case, if that's the only functionality you're using, it's doubtful that there's really any difference to that functionality in Distribute, especially in the case of packages that aren't installed in zipfile format. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] installing .py plugins to an alternate directory
At 01:06 AM 12/3/2009 +0100, Andrew Dalke wrote:
Hi all,
I'm working with the Akara project. It contains a web server. The
server loads extensions from a special directory (let's say
$AKARA for now). An extension can register handlers for URLs. An
example extension might look like:
installs to $AKARA/spam_extension.py
(note: only .py files are supported; not even .pyc files)
=
from akara.services import simple_service
import my_spam # This is part of the distribution, and gets put in
site-packages
@simple_service(GET, http://vikings.protocol.id/;)
def vikings(say=my_spam.DEFAULT_TEXT):
return my_spam.vikings(say)
=
We want people to be able to distribute Akara plugins and install
via setup.py. Ideally I would like to say:
from distutils.core import setup
from akara.distutils ... I'm not sure what here ...
setup(name=Spam services,
package=my_spam,
akara_extensions=[spam_extension.py]
)
To clarify, the development/distribution package looks like:
$PACKAGE/setup.py
$PACKAGE/README
$PACKAGE/spam_extensions.py
$PACKAGE/my_spam/__init__.py
$PACKAGE/my_spam/dramatis_personae.py
$PACKAGE/my_spam/cafe.py
and $PACKAGE/spam_extensions.py goes to $AKARA/spam_extensions.py
while $PACKAGE/my_spam is copied to site-packages.
The installation does not need to byte-compile spam_extension.py.
It should also include spam_extension.py in any distribution that it makes.
I looked through the documentation and searched for existing
examples, but found nothing which does this. The plugins I found
used entry_points, and that's an architecture change which I don't
think is appropriate for us.
It wouldn't be so much of a change as an addition. You'd just add
code like this, either before or after your existing loop over the
extensions directory:
for entry_point in pkg_resources.iter_entry_points('akara'):
extension_module = entry_point.load()
# do stuff with extension_module
And then users would declare their extensions for installation like this:
setup(name=Spam services,
packages=[my_spam],
py_modules=[spam_extension],
entry_points={'akara':'Spam services=spam_extension'} #
arbitrary name=module
)
Everything else would be the same as you described above with respect
to layout, except:
1. the spam_extension module would be installed in site-packages
2. It wouldn't need to be a top-level module (i.e., it could be a
module in the package)
3. You don't need any custom distutils extensions, except what you
get via setuptools or Distribute.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 70 packages in total use setuptools' extras feature
At 10:21 AM 12/3/2009 -0800, Sridhar Ratnakumar wrote: Do you have anything particular in mind? What I did was a ``grep ^.*[a-zA-Z]\[`` in the requires.txt of (almost) all the packages in PyPI. Do note that this won't tell you about end users' use of extras. The main use case described in the documentation for extras is allowing users to install optional support for things. That means you're more likely to see them in buildout configurations (which won't be found on PyPI), and manual installation steps (which aren't recorded anywhere). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] specifying a requirement on multiple setuptools extras
At 08:25 PM 12/3/2009 +, Chris Withers wrote: Hi All, Say I have a package, mortar, that offers multiple extras options for different data storage mechanisms, eg: sqlalchemy, zodb, simpledb If I want to use this in a project and want both the sqlalchemy and zodb backends, how do I spell this? easy_install mortar[sqlalchemy,zodb] Just like that. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 70 packages in total use setuptools' extras feature
At 09:53 PM 12/3/2009 +0100, Attila Oláh wrote: Wouldn't it require zope.component to be a namespace package? Extras allw you to add extra files (subpackages) withot making the container package a namespace-package, it seems to me. No, they don't. Extras just cause a project to pull in additional dependencies, not additional *files*. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] installing .py plugins to an alternate directory
At 12:34 AM 12/5/2009 +0100, Andrew Dalke wrote: I had some concerns about them. For one, all of the plugins define out-word facing web services on our server. If the plugins can be located in arbitrary locations inside of site-packages, how does the administrator know which plugins will be activated? How does the admin enable/disable a plugin for testing or security reasons, except by changing the entire package installation? Then install the plugins as eggs to the plugin directory, rather than installing them in site-packages. If the admin wants to change the URL for a given service from /spam to /spam_and_eggs, which is currently done as configuration data in the installed plugin, file, that is, by changing # default service name is base on the function name. This becomes /spam @simple_service(GET, http://protocol.id/;) def spam(): return Spam! -to- @simple_service(GET, http://protocol.id/;, spam_and_eggs) def spam(): return Spam! It does not seem like changing the installed package will be so simple. Indeed. It would be much better to make your service decorator read overrides from a configuration file, so that the decorator values are merely defaults. Editing source code is a lousy way to do configuration, when there's stuff in the file besides configuration. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] installing .py plugins to an alternate directory
At 01:18 AM 12/5/2009 +0100, Andrew Dalke wrote: It appears that pkg_resources does some caching, including using linecache. I can't tell how well it would work if our pluging packages were updated after the main server was running. If you need to ensure that you get a fresh list of plugins each time, you can use for entry_point in pkg_resources.WorkingSet().iter_entry_points(...). Or more precisely, you can create a new WorkingSet() whenever you want to start over with a clean cache. (Btw, the only thing pkg_resources uses linecache for is to ensure that the source of a script loaded from an alternate location is viewable in linecache as though it came from the location the script was run from. This is a debugging aid only, and doesn't have any effect on anything that's not trying to dump out source code lines (such as an error reporting tool, or the Python debugger).) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Bug] Failed installation. setuptools-0.6c11.win32-py2.6.exe
At 01:32 PM 12/9/2009 +0100, Rune Strand wrote: Hi, setuptools-0.6c11.win32-py2.6.exe will not install on Win 7 with python 2.6.4 installed. Dialog says: Python version 2.6 is required, which was not found in the registry That seems to be an indication that Python itself is not properly installed on your machine -- it should be in the registry. I run py32 on win64 C:\python Python 2.6.4 (r264:75708, Oct 26 2009, 07:36:50) [MSC v.1500 64 bit (AMD64)] on win32 How was it installed? Did it come with your PC, or did you install it? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Problems with setuptools 0.6c11, Mac OS X 10.6, Python 2.4 from MacPorts
At 04:10 PM 12/9/2009 -0700, Jeff Shell wrote: I've been getting strange behavior with trying to use Buildout with setuptools pinned to 0.6c11 on Mac OS X 10.6, with Python 2.4 built from MacPorts. I'd constantly get the following error: Getting distribution for 'zope.interface==3.5.2'. No eggs found in /var/folders/ta/taVYwGZqHuKHt5V7rcwEzE++-+s/-Tmp-/easy_install-7kLZlO/zope.interface-3.5.2/egg-dist-tmp-dC9GYL (setup script problem?) I first noticed it when trying to use a fresh 'bootstrap.py' from zc.buildout (which I have traditionally not used in our projects), and tried the 'Use Distribute' option. What was interesting was that `zope.interface` 3.5.2 was already installed in my eggs directory, and buildout should not have been trying to get a new one. So this problem seems to show up with both Distribute (0.6.8?) and setuptools (0.6c11). Pinning setuptools to 0.6c9 does not have this problem. I don't know if this is related, but when comparing the setuptools 0.6c9 and 0.6c11 source trees, I noticed a change in how the Mac OS X version is looked up: Yep, that would cause the problem you're showing above. I'll make a note to change the version check code to fall back if mac_ver() gives spurious results. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Bug] Failed installation. setuptools-0.6c11.win32-py2.6.exe
At 05:17 PM 12/15/2009 +0100, Andrey Andreev wrote: Hi Rune, I had a similar issue on Windows Server 2008 R2. You are probably running Win 7 (64bit). I ran procmon, and found out that the installer is looking for the keys under: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore HKEY_CURRENT_USER\Software\Python\PythonCore so I modified the register.py discussed above to write to HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE, which solved the issue. Sounds like maybe there's a problem with either the distutils or the Windows Python installer, since either the bdist_wininst isn't checking in the right place, or the Windows Python installer isn't registering in the right place. (i.e., this would be an issue with *any* Python .exe-based installer on these platforms.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Install egg from SVN sources = AttributeError: 'module' object has no attribute '__getstate__'
At 06:10 PM 12/17/2009 +0200, Eemeli Kantola wrote: Hi all, I'm getting a crash in setuptools-0.6c11-py2.6 when trying to install an egg directly from SVN sources. This happens both on OSX and Ubuntu, versions: Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) [GCC 4.3.3] on linux2 Command and stack trace: ... So is this a bug? My fix is presumably only treating the symptoms, because I've got only little clue of what is happening in the code... My guess is that you've got some other pkg_resources module on your sys.path, such as from an older version of setuptools. Could you check the following from your Python prompt? import pkg_resources, setuptools print pkg_resources.__file__ print setuptools.__file__ print setuptools.__version__ Thanks. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] install_requires option to force pypi url or a better approach?
At 06:12 PM 12/18/2009 +0100, Aljoa MohoroviÄ wrote: i've setup private pypi where i can upload some packages that are not suitable for pypi.python.org. my package, let's call it myapp, contains install_requires=['django',] but with that requirement i can't install it. -- $ virtualenv --no-site-packages --distribute env New python executable in env/bin/python A globally installed setuptools was found (in /usr/lib/python2.6/dist-packages) Use the --no-site-packages option to use distribute in the virtualenv. Installing distribute...done. $ . env/bin/activate $ pip freeze distribute==0.6.8 wsgiref==0.1.2 $ pip install myapp -i http://pypi.example.com Downloading/unpacking myapp  Using download cache from /home/aljosa/.pip-cache/MYAPP PKG URL  Running setup.py egg_info for package myapp Downloading/unpacking django (from myapp)  Could not find any downloads that satisfy the requirement django (from myapp) No distributions at all found for django (from myapp) -- since i can normally install django with pip install django i assume that when i set -i http://pypi.example.com; it's also used for install_requires. any tips on using multiple pypi repositories? is there some way to define which pypi url to use for package installation? You would probably be better off using the find_links option in your setup(), to indicate additional URLs where packages can be found. e.g. find_links=['http://pypi.example.com/somepackage', 'http://pypi.example.com/otherpackage']. This will tell easy_install (or other packaging tools) to check these pages in addition to the standard package-index pages, when seeking out your dependencies. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Packaging of files, which aren't in the package root folder
At 08:44 PM 12/20/2009 +0100, Lukas Hetzenecker wrote: I found a simpler way to do this - Is there any drawback if I try to solve this problem using this way: Yes. The --record option to the install command will be broken (due to not including the directly-copied files). (And that's only the *first* problem that comes to mind. I'm pretty sure there are others.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Specifying eggs and build manifest ?
At 10:24 AM 12/22/2009 +0900, David Cournapeau wrote: 1 Formally specifying the egg format (and versioning it !) - or is egg format outside distribute goal ? FYI: http://peak.telecommunity.com/DevCenter/EggFormats ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] packaging terminology confusion
At 10:29 AM 1/7/2010 -0600, Brad Allen wrote: On Thu, Jan 7, 2010 at 9:12 AM, John Gabriele jmg3...@gmail.com wrote: On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele jmg3...@gmail.com wrote: The only inconsistency, I think, is that operating systems like Debian refer to their software distributions as packages (as in, a packaged up piece of software that you can download and install). Packages is a great name for them -- too bad it's already being used in Python. I believe that's basically where the confusion comes from. Whoops. Just noticed that the front page of the PyPI says: There are currently 8614 packages here. (is that 8614 packages or 8614 distributions?) 8614 *projects*, some of which have one or more *versions*, which in turn may have one or more source or binary *distributions*. That at least is the terminology that setuptools and distribute use in their documentation at the moment. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] packaging terminology confusion
At 09:20 PM 1/7/2010 +0100, Martin v. Löwis wrote: 8614 *projects*, some of which have one or more *versions*, which in turn may have one or more source or binary *distributions*. Instead of version, I really like PyPI's term more: *releases*. Not all versions are released versions, so I suppose it's actually: project - version - release - distribution As for projects: fine with me; PyPI would then be the Python Project Index. +1. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
At 11:00 AM 1/8/2010 -0600, Brad Allen wrote: On Fri, Jan 8, 2010 at 10:29 AM, Lennart Regebro rege...@gmail.com wrote: Just my 2 cents: - The definitions that Tarek proposed it exactly how I already use the words. - I think Python Project Index is a better name than Python Package Index. But Cheese Shop is still better. :) That's all I have to say about it. :-) I also liked the 'CheeseShop' name, but what does that leave our setup.py thingies being called? Cheeseballs, maybe? Consulting a thesaurus yields one word that nobody has proposed yet: Parcel. Helpfully, it still starts with P, so we could rename it the Python Parcel Index. I have a dim memory hearing this word in a jargon-y context before, but it's certainly considerably more obscure than package, distribution, archive, et cetera. Anybody else like that one? Yes, very much. I like 'parcel' better than 'project', partly because it's not already overload with other contextual meanings. This is just another example of the degree of confusion around terminology here, because parcel isn't a substitute for project: a project is something that you would release parcels *for*. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
At 09:13 AM 1/9/2010 -0600, Brad Allen wrote: On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby p...@telecommunity.com wrote: Yes, very much. I like 'parcel' better than 'project', partly because it's not already overload with other contextual meanings. This is just another example of the degree of confusion around terminology here, because parcel isn't a substitute for project: a project is something that you would release parcels *for*. These two terms have yet to be formally adopted, so they can mean what we want them to mean. You miss my point: the usage of project you were commenting on was not in reference to the same thing as your comment. In the context of the thread, project was referring to thing that has releases and parcel was being used as a substitute for the existing term distribution or module distribution. (And even if it's *me* who's confused here, the point still stands about the degree of confusion. ;-) ) Anyway, IMO parcel works great as a substitute for distribution (as it is a concrete term for a concrete thing) and not so great as a substitute for project (since a project isn't that concrete a thing and parcel therefore seems *too* concrete). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
At 05:32 PM 1/10/2010 +0100, Lennart Regebro wrote: On Sun, Jan 10, 2010 at 16:24, Brad Allen bradallen...@gmail.com wrote: I had thought 'egg' was just another distribution format, an alternative to tarball, etc. But I have heard people at my local user group use it to mean 'module distribution'. Yeah, there is some confusion there. As I understand it, 'Egg' isn't even a distribution format, Right - it's an importable (i.e. addable-to-sys.path) binary distribution with project release metadata attached. .egg files, .egg directories, and flat installations with associated .egg-info directories are all eggs. (Also, since Python 2.5+ distutils generate .egg-info files, all distutils-installed module distributions from Python 2.5 on are technically eggs.) and egg is a package that has extra information. Actually, it's a project release with extra information - packages may or may not be involved, since an egg may contain only a script or some modules. There is also a distribution format, .egg, but a tarball that includes a .egg-info directory is an egg. Technically, the tarball *contains* an egg, but is not itself an egg, since it cannot be added to sys.path (at least not without using some PEP 302 and pkg_resources hooks that nobody has actually used yet, AFAIK). A tarball that doesn't, but has a setup.py, is not an egg, but may be used to make it one. Actually, if the tarball was generated by setuptools, then its contents may also be an egg (since as part of the sdist process, an .egg-info directory is generated. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] refining the idea of entrypoints and their metadata
At 11:24 PM 1/11/2010 +0100, Ronny Pfannschmidt wrote: Hi, while toying with the entrypoint system, i repeatedly ran into the need of having additional metadata prior to importing In Plugins that only handle certain filetypes/extensions/mimetypes might profit from the additional metadata (while also defering imports) The same goes for my library anyvc that needs to know what directories to check for, however usually the directory checking is a lot faster than doing the imports (and implementing custom lazy importing is pain). So i propose supporting to store additional metadata along with the entrypoints. Just FYI, there is nothing stopping you from implementing something like this with an egg_info writer plugin and a custom setup argument: http://peak.telecommunity.com/DevCenter/setuptools#adding-setup-arguments http://peak.telecommunity.com/DevCenter/setuptools#adding-new-egg-info-files You could then use the pkg_resources discovery APIs to find distributions: http://peak.telecommunity.com/DevCenter/PkgResources#getting-or-creating-distributions And then pull out the metadata via the API: http://peak.telecommunity.com/DevCenter/PkgResources#imetadataprovider-methods This is exactly how standard entry points are implemented now, so you can use this as a guide. The i18n support for Chandler uses a similar approach, bundling a resources.ini in the egg_info metadata, that lists message catalogs and other localization resources included in the relevant plugin. (Chandler plugins can provide translations for strings in other Chandler plugins, so that e.g. you can distribute a multi-plugin localization plugin.) (Btw, these comments should not be construed as saying a more sophisticated system is a bad idea or anything like that, I'm just pointing out that you need not wait for someone else to implement this for you, as the hooks to do it on your own are documented and ready to use. And perhaps you can then promote your implementation as a defacto or dejure standard. ;-) ) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Distutils roadmap of refactoring for 2.7
At 06:29 PM 1/23/2010 +0100, Tarek Ziadé wrote: 2010/1/23 P.J. Eby p...@telecommunity.com: At 01:00 PM 1/23/2010 +0100, Tarek Ziadé wrote: 3 - dir_util, archive_util and file_util are going to be removed in favor of calls to shutil. By removed, do you simply mean that distutils will stop using them, but the modules will still be there? (i.e., deprecated and phased out, rather than simply dropped from existence altogether.) I'll use the same strategy than sysconfig : - if the API is just moved to another place and works exactly the same way (e.g. like what's planned for make_archive), it will be dropped, and the documentation will refer to the new place. Is this the standard procedure for relocation of stdlib APIs across 2.x releases? I was under the impression that the standard is to do such things across two release cycles with a deprecation. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute 0.6.10 and convert_2to3_doctests
At 04:05 PM 1/29/2010 -0500, Barry Warsaw wrote:
The important thing is to have exactly one place to set
the package's version number.
Put it in setup.py, then. If you absolutely must have a __version__
at runtime, use this to extract it from the installation metadata:
__version__ = pkg_resources.require('MyProject')[0].version
Mostly, though, I don't bother with having a __version__ in my
modules or packages any more, since you can just do the above if you
want to check the installed version of something.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute 0.6.10 and convert_2to3_doctests
At 07:08 PM 1/30/2010 -0500, Barry Warsaw wrote:
On Jan 29, 2010, at 11:03 PM, Tarek Ziadé wrote:
Yes, that's how Jinja does already for example, using Setuptools's
pkg_resources :
__version__ = __import__('pkg_resources').get_distribution('Jinja2').version
And that's different yet again from what PJE suggests.
Not really; just a different way of spelling the same thing. In
either case, you're looking at the .version attribute of the
Distribution instance.
This is screaming for
a blessed API to be pushed into the stdlib.
(BTW, why use __import__() there?)
It lets you save an extra line to import pkg_resources; that's really
the only difference.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] modules in different folders but under same namespace
At 05:53 PM 2/4/2010 +0100, Riccardo-Maria BIANCHI wrote: Hi, I have a package structured like this: package/__init__.py src/ __init__.py mod1.py share/__init__.py mod2.py Now I can import them as: package.src.mod1 package.share.mod2 How can I use Distutils to be able to import both of them under the same package namespace as: import package.mod1 import package.mod2 Move mod1.py and mod2.py under package/, and delete the subdirectories. If you need backward compatibility, leave the old subdirectories and files in place, but have them import the new ones instead of containing any code. Then delete them later. Munging __path__ or using the package_dir options to setup() are both bad ideas in this case, unless there are other requirements you haven't stated. If you use the __path__ approach, you're going to make it more difficult for the distutils to figure out what to include in your source and binary distributions and installs, and if you use package_dir, you're going to end up with a different installation layout than your source layout. Both will likely lead to hassles down the road, even if they appear to work in the short term. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 376 -- new round
At 01:55 AM 2/5/2010 +0100, Tarek Ziadé wrote: I think it's still useful, because it points the root packages that can be removed safely without breaking the system -- even if leaving orphaned packages behind. Any opinion ? I think it's a good idea to have a way to tell what packages were *not* installed to satisfy dependencies. Merely plotting the dependency graph doesn't tell you this, because you could have a non-root orphan - i.e., something that was installed to fill a dependency, but the depender(s) have now vanished. I guess what I'm saying is, a thing that is not needed by anything else could either be an orphan (due to other uninstalls) *or* a root (manually chosen for install), and there is no way to tell them apart just by following the graph. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 376 -- new round
At 07:37 AM 2/5/2010 -0600, Ron Adam wrote: Because files from eggs can be installed in multiple directories, and some of those are in arbitrary locations, Scripts are the only things that get installed to other directories from .eggs. Everything else is within the .egg file or directory. It's non-.egg installs that have the problem you describe. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 376 - RECORD file / Data files + pip feedback ?
At 01:39 PM 2/5/2010 -0500, Carl Meyer wrote: What if RECORD allowed either absolute paths or paths relative to the location of .egg-info, but nothing else? That would preserve the option for application authors to make relocatable self-contained installations, while keeping RECORD simple and useful for uninstall without relying on prefix-finding magic. I'm confused about something here. There will still be a PREFIXES file, right? So you shouldn't need prefix-finding magic except in the case where something has been relocated, right? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 376 - RECORD file / Data files + pip feedback ?
At 06:10 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote: On 2010-02-05, at 4:57 PM, P.J. Eby wrote: At 04:49 PM 2/5/2010 -0800, Sridhar Ratnakumar wrote: Do we have a real-world example for installing uninstallable data files outside sys.prefix? Scripts aren't always in sys.prefix, Scripts *usually* go to sys.prefix/bin (or sys.prefix/Scripts or site.USER_BASE/Scripts). Are their packages that actually put them elsewhere? It's not the package that determines installation locations, it's the user's command line options and configuration file settings that determine the locations for libraries, scripts, and data files. Also make sure you're not forgetting e.g. shared hosting scenarios without a virtualenv, unless you're planning to make virtualenvs an officially-supported thing. In such cases, the paths involved won't necessarily fall into a single root. PyPM is an ActivePython tool which installs itself into, say, /opt/ActivePython-2.6 - a single root directory. So we never had to worry about other layouts. PyPM supports virtualenvs too, so pypm -E /tmp/myenv install lxml would install into the specified virtualenv. Also don't forget sys.exec_prefix. (Isn't packaging fun?) In ActivePython, sys.exec_prefix == sys.prefix. Yes, well, as I said, isn't packaging (in the wider Python world, where few such simplifications can be had) fun? ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools and additional scripts handling
At 02:23 PM 2/16/2010 +0100, Manlio Perillo wrote: Is it possible to declare a custom directory where some of the scripts needs to be installed? No. However, you can always create a script whose job is to symlink your other scripts to the appropriate cron directory, and ask your users to run it after installation. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools and additional scripts handling
At 04:37 PM 2/16/2010 +0100, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 P.J. Eby ha scritto: At 02:23 PM 2/16/2010 +0100, Manlio Perillo wrote: Is it possible to declare a custom directory where some of the scripts needs to be installed? No. However, you can always create a script whose job is to symlink your other scripts to the appropriate cron directory, and ask your users to run it after installation. Can't this be done inside setup.py? You could make a setup command, or customize the install command, but neither of these things would affect easy_install or pip. If you allow the scripts to be installed to standard locations, then they will contain the correct interpreter, and will only need to be symlinked to the cron.hourly or cron.daily or whatever else it is you're wanting to do. (Heck, if what you've got is a singleton application of some sort, you could potentially just have it check at startup that the cron scripts are symlinked, and let the user know about the problem.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools and additional scripts handling
At 09:11 PM 2/16/2010 +0100, Manlio Perillo wrote: You are right, this is a singleton web application! So, it will not be installed using pip or easy_install. I have to decide if it is best to abuse setuptools plugin support, in order to install system services (cron scripts, init.d script) or if it is better to provide a separate script, as you suggested. You can also extend the install command, and this could be made to work with plain distutils, as well as setuptools. (Subclassing distutils commands is a standard practice, described in the documentation for distutils.) It just means that programs that don't use install to do the installation won't work correctly, if at all. However, if you just want setup.py install to do things differently, subclassing the install command is the way to go. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] include special filetypes and subdirectories
At 01:34 AM 2/19/2010 +0100, Assem Chelli wrote: Hi how to change setup.py to include special filetypes and subdirectories recursively in python eggs Option 1: Put them under revision control using CVS, Subversion, or any revision control system that has a setuptools plugin (in which case, you'll need the plugin installed in your development environment). Then, add 'include_package_data=True' in your setup() call. Option 2: Use the package_data setup() argument (see the distutils docs), and explicitly list the files and directories to include. This is not recursive, but will also work with plain distutils. Option 3: Use a MANIFEST.in file (see the distutils docs) and specify the directories to include, and also place 'include_package_data=True' in your setup() call. Of these, option 1 is generally the best option since it doesn't require you to maintain information in two or more places; the files are included as a side effect of your ordinary development practices, as long as you're using a revision control system. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] include special filetypes and subdirectories
At 02:11 AM 2/19/2010 +0100, Assem Chelli wrote: i have eclipse with cvs and pydev plugin's ,how can i do it,or its automatically If your files are under CVS control (in which case you will have a bunch of directories named CVS in your project), then all you need is to add the include_package_data=True in your setup(). 2010/2/19, P.J. Eby p...@telecommunity.com: At 01:34 AM 2/19/2010 +0100, Assem Chelli wrote: Hi how to change setup.py to include special filetypes and subdirectories recursively in python eggs Option 1: Put them under revision control using CVS, Subversion, or any revision control system that has a setuptools plugin (in which case, you'll need the plugin installed in your development environment). Then, add 'include_package_data=True' in your setup() call. Option 2: Use the package_data setup() argument (see the distutils docs), and explicitly list the files and directories to include. This is not recursive, but will also work with plain distutils. Option 3: Use a MANIFEST.in file (see the distutils docs) and specify the directories to include, and also place 'include_package_data=True' in your setup() call. Of these, option 1 is generally the best option since it doesn't require you to maintain information in two or more places; the files are included as a side effect of your ordinary development practices, as long as you're using a revision control system. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] using distribute instead of distutils
At 05:20 PM 2/22/2010 +0100, Jean Daniel wrote: Hello, I am writing a pure python module called wordish, which is similar to doctest in that it test snippets of code, parsed from an rst article and produce a report. wordish is available on Pypi in version 1.0 and the documentation is available at jdb.github.com/wordish. So far, I only distributed one file, *wordish.py* and the file was used like the following:: Â Â Â python -m wordish my_article.rst I think I will turn to 'distribute' for the future release so that console entry points can be created automatically and installed in the shell path. I would like wordish to be used in this way:: Â Â Â wordish my_article.rst I have read the documentation for distutils, distribute but still, but the overlap that the tools, and the problems that each tool solve. Can my setup.py support the installation of the following files, or should they be included in debian/fedora packages instead? 1. few examples files? 2. static html documentation files? 3. man pages for the console scripts? The distutils doesn't really support installing such things well; you can certainly include them in your *source* distribution, though. Also, I upload a source distribution (sdist) to the Python Package Index 4. should I use an *egg* instead? No, it's not necessary. Eggs are mainly useful as a drop-in-and-use format for application plugins (such as extensions to Chandler, Trac, and other plugin-enabled application environments), and distributing precompiled C extensions on certain platforms. easy_install and pip can both operate just fine on source distributions, and if your code is only pure Python, you don't need to distribute binaries. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools-0.6c11.win32-py2.6.exe
At 04:13 AM 2/21/2010 +0100, Daniel Niccoli wrote: Hello Phillip, if you install the x86-64 version of python, the windows installer setuptools-0.6c11.win32-py2.6.exe does not find any Python installation. I had to export the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Python, change it to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python and import it afterwards to be able to install the software. The installer should be changed to avoid trouble for other people. This is a *Python* installer issue; Please see: http://bugs.python.org/issue6792 Until the issue in Python itself is fixed, the only things I can do are document the problem and/or stop distributing an .exe installer. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] from distutils.core import DistutilsOptionError
At 05:32 PM 2/23/2010 -0500, Tarek Ziadé wrote: 2/ the work done in 2.7 so far was following the usual deprecation process for relocated APIs or removed APIs, but nothing for misplaced import statements. We did discuss this in the past and said it was fine this way. Btw, imports from distutils.core *are* API; its docstring describes it as The only module that needs to be imported to use the Distutils. It's supposed to be a one-stop shop for importing common things needed by setup scripts, including the errors, Extension, Command, Distribution, etc. So, the unused imports in distutils.core are not misplaced import statements, nor is there a good reason (AFAICT) for changing the API to require the average setup script author to remember which module to import things from. There should be only one obvious way to do it, and right now, the one obvious way to import things in a setup script is from distutils.core. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] from distutils.core import DistutilsOptionError
At 06:05 PM 2/23/2010 -0500, Tarek Ziadé wrote: Or do you mean that you consider the exception classes located in Distutils to be a common need for people that write setup.py scripts ? A setup script may want to explicitly throw (or catch) distutils errors, and having only one place to import these things from makes distutils easier to use. I don't consider it a *common* need, but I do consider it part of distutils' core API, in the sense that if your code is either invoking distutils or being invoked by it, you may need to throw or catch those errors. In general, everything that's a *distutils-defined* symbol (not types, os, etc.) in distutils.core, I thought was intended to be imported from there, as they are all things that could be considered part of the core API. (And apparently, at least Thomas thought the same thing.) (If I'd been writing distutils, I'd have named the module distutils.api rather than distutils.core, and explicitly created an __all__ list for it, but it's pretty much the same thing.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: Barely minimal CI + tests + packaging in Python WAS: Guidelines for where to put tests how to package them
At 10:16 AM 2/26/2010 -0500, Olemis Lang wrote: Well not as happily as I thought in first place. The fact is that `setuptools` test command creates the runner by calling the class specified in `test_runner` arg but supplies no parameters. In this case I'd like to specify `xmlrunner:XMLTestRunner` (is that the correct syntax ?) to obtain a JUnit XML report, but I need to specify the path where those reports will be outputted, so that the CI tool (Hudson in this case) can publish'em and generate the nice graphs we all love . Considering the current implementation, I still need to override `run_tests` method as a whole, and repeat 99% of what is implemented in there, in order to get the exact runner I need :( My suggestion (hint, $0.02 ... whatever ;o) is 1. use a factory method (e.g `create_runner` ) returning an instance of test runner. This method could be overridden by subclasses if further options or whatever needs to be considered to instanciate the runner I'm confused. Why don't you just set test_runner to point to your factory function, then? That's what nose does. (Well, in its case it's the test_loader, but same basic idea.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] RFC: Barely minimal CI + tests + packaging in Python WAS: Guidelines for where to put tests how to package them
At 11:19 AM 2/26/2010 -0500, Olemis Lang wrote: On Fri, Feb 26, 2010 at 10:52 AM, P.J. Eby p...@telecommunity.com wrote: At 10:16 AM 2/26/2010 -0500, Olemis Lang wrote: Well not as happily as I thought in first place. The fact is that `setuptools` test command creates the runner by calling the class specified in `test_runner` arg but supplies no parameters. In this case I'd like to specify `xmlrunner:XMLTestRunner` (is that the correct syntax ?) to obtain a JUnit XML report, but I need to specify the path where those reports will be outputted, so that the CI tool (Hudson in this case) can publish'em and generate the nice graphs we all love . Considering the current implementation, I still need to override `run_tests` method as a whole, and repeat 99% of what is implemented in there, in order to get the exact runner I need :( My suggestion (hint, $0.02 ... whatever ;o) is 1. use a factory method (e.g `create_runner` ) returning an instance of test runner. This method could be overridden by subclasses if further options or whatever needs to be considered to instanciate the runner I'm confused. Why don't you just set test_runner to point to your factory function, then? That's what nose does. (Well, in its case it's the test_loader, but same basic idea.) Well in theory it is possible (and did not think about that in the first place, thnx ;o) but : 1. How could I know about extra command line params (without parsing them once again of course ;o) ? 2. In the case of the build script, I'm writing a setup script rather than a framework (e.g. nose). 2.1 The XML runner is not always used, but only when running at the CI buildenv (I supposed I could just use `-r xmlrunner:XMLTestRunner` but I need an extra arg) How could I specify output path in cmdline ? An environment variable would solve these problems, at least if you have a decent shell. ;-) 2.2 So I suppose I should write a function to do that but - Under tests pkg? ... (Unit | functional | ...) tests don't need it - In setup.py itself ? ... What should I supply in to -r arg ? If you are running setup.py from the command line (as opposed to programmatically via easy_install), then it's __main__:whatever. (It won't work if setup.py isn't the true __main__, though, e.g., if the script is being execfile'd.) How could I specify output path in cmdline ? 3. In the case of `dutest` well ... that could help (depending on the answer to 1 ;o) 3.1 How could I reuse features already stored in `Distribution` (especially values set after finalize_xxx ) ? You can't, unless you... 4. (Hypothetical so far, so I'm prepared to receive tomatoes ;o) What if I want to reuse (subclass) `test` command ? Which is perfectly allowable. You'll just have to duplicate that one method. Of course, if you write a suitable patch to refactor it to call another method, I'll happily put it in the trunk, since you're working from trunk to get the test_runner feature anyway. (Suitable = tested by you, doesn't break or remove existing functionality, other I'll know it if I see it criteria ;-) ) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [TIP] Guidelines for where to put tests how to package them
At 02:27 PM 2/26/2010 -0500, Olemis Lang wrote: test_suite is ( supported | introduced | defined ) by setuptools.comand.test.test class Is it required to be a callable yep No. test_suite is to be an object recognized by the test_loader as convertible to a unittest TestSuite. For example, a module, TestCase subclass, etc. You are probably thinking of the test_runner option, not test_suite. test command performs test discovery (as a last recourse AFAICR, /me cc-ing to P.J. Eby because probably he has further updates ;o) using a loader: setuptools.comand.test.xxx Setuptools' test loader will scan modules and packages, but you still have to tell it where your top-level test package or module is. (The test_suite.) BTW, I am strongly -1 for using the discovery protocol introduced in 2.7 (AFAICR), specially because it collides with test_suite and many other arguments ... so it would be very nice when defining packaging conventions, layout ... not to enforce the use of that protocol, so that if another discovery is used then it could still be compatible with the more abstract good practices. (all this said from my selfish position, I confess) I'm not sure what you're talking about here; I'm not much in the loop for what's going on with distutils updates, and even more so for unittest updates. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] layout and setup.py for packaging documentation
At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote: Can this be simpler? Yes. Don't install docs with your package. People who want them installed locally can just download your source install or use easy_install -e. Also, if your module is popular enough that people make Linux system packages for it, they will make sure the docs get put in a blessed install location. Python doesn't currently have a blessed install location for documentation, though perhaps it *should* have one in distutils2. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] layout and setup.py for packaging documentation
At 10:39 PM 2/28/2010 +, Michael Foord wrote: On 28 February 2010 22:14, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 10:03 PM 2/28/2010 +0100, Jean Daniel wrote: Can this be simpler? Yes. Don't install docs with your package. People who want them installed locally can just download your source install or use easy_install -e. Also, if your module is popular enough that people make Linux system packages for it, they will make sure the docs get put in a blessed install location. Python doesn't currently have a blessed install location for documentation, though perhaps it *should* have one in distutils2. How to include documentation in a package is a common question, so it would be great if distutils2 could deal with this issue. My current solution is, as Phillip suggests, to not include the docs in distributions available via PyPI and to provide a more 'complete' download separately. That's not what I suggested, actually. I said, don't *install* docs with your package. Do *include* them in your source distribution, though, so people can download and read them with easy_install -e, and also so that those system packagers only have to download one tarball. You also need only produce a standard source distribution (setup.py sdist upload) for PyPI. In other words, Jean Daniel should retain his source layout of: wordish-1.0.2/ setup.py wordish.py docs/ index.html command-ref.html And simply make sure that docs/ is under revision control (setuptools) or add a recursive-include docs to MANIFEST.in (distutils). Then, setup.py sdist will build a correct tarball. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools error when using --prefix option, complains directory does not exist
At 02:57 PM 3/9/2010 -0500, hari jayaram wrote: Hi I am installing setuptools using the --prefix option it complains the directory does not exist even though it does. The install works however when I use the --instal-dir option as it recommends. macbook-pro-17:~ hari$ sudo sh setuptools-0.6c11-py2.6.egg --prefix=/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages That's because the directory you gave is not a *prefix*, it's an installation directory. A prefix, in distutils terms, is generally the top-level directory under which Python's lib, bin, and other directories are located. So, the correct --prefix would be /Library/Frameworks/Python.framework/Versions/2.6 in this case. (Notice the absence of lib/python2.6/site-packages.) [Errno 2] No such file or directory: '/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/lib/python2.6/site-packages/test-easy-install-79530.pth' If you look closely at this path, you'll see that when the distutils creates an install directory from your prefix (which is already an installation directory), you end up trying to install to a 'lib/python2.6/site-packages/lib/python2.6/site-packages' directory. That's because when you give a prefix, distutils decides what subdirectories of the prefix to install things in, and it can't tell that you already gave it a subdirectory of the prefix. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] use of '_' in package name causing version parsing issue?
At 03:03 PM 3/9/2010 -0600, Brad Allen wrote:
Today I was informed of an issue in which buildout (with the latest
setuptools) is not resolving version numbers properly, causing the
wrong package to be selected in some cases. The cause identified was
having '_' in the package name.
I suspect there is a miscommunication or misunderstanding
somewhere. It is perfectly acceptable to have a '_' in a package
name or project name. This:
| a=jiva_interface-2.3.6-py2.6.egg
| b=jiva_interface-2.3.8-py2.6.egg
| pkg_resources.parse_version(a)
Is the wrong API to use to parse an egg filename, as parse_version()
is for parsing a version that's already extracted from a
filename. This is the right API for extracting a version from a filename:
pkg_resources.Distribution.from_filename(a).version
'2.3.6'
pkg_resources.Distribution.from_filename(b).version
'2.3.8'
pkg_resources.Distribution.from_filename(c).version
'0.1.1'
pkg_resources.Distribution.from_filename(d).version
'0.1.2'
And here's the correct one for extracting the parsed version from a filename:
pkg_resources.Distribution.from_filename(a).parsed_version
('0002', '0003', '0006', '*final')
pkg_resources.Distribution.from_filename(b).parsed_version
('0002', '0003', '0008', '*final')
pkg_resources.Distribution.from_filename(c).parsed_version
('', '0001', '0001', '*final')
pkg_resources.Distribution.from_filename(d).parsed_version
('', '0001', '0002', '*final')
As you can see, these APIs work just fine, so the example given is a
red herring, unless Buildout is using the APIs incorrectly (which I
really doubt it is).
Usually, the situation where people run into trouble with unusual
package names or filenames is when they produce a source distribution
manually, or by using something other than distutils/setuptools (that
has different filename escaping rules), or when they manually rename
a file before uploading, and expect it to still work the same.
It would be a good idea for you to check which of these things (if
any) is taking place, and provide details of the specific problem,
with steps to reproduce it, since the example given probably has
nothing to do with it. Thanks!
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
