Re: [Distutils] Twisted plugin system and Python packaging
At 08:52 PM 9/25/2011 -0400, Glyph Lefkowitz wrote: On Sep 25, 2011, at 1:44 AM, P.J. Eby wrote: (These are all packages that are distutils-only, though, or have their own extensions, IIRC.) You mean extensions to distutils, or C extensions? The former. The mx.* stuff has a mx_setup or some such distutils extension. Not sure about the ll.* stuff. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Twisted plugin system and Python packaging
At 04:20 PM 9/21/2011 +0200, Tristan Seligmann wrote: If you include twisted.plugins in your setup.py, then this works fine with distutils setup.py install as well as pip install; setuptools setup.py install will install everything into an egg, which will also work due to the way __path__ is set. However, since twisted ends up in top_files.txt in the egg-info, pip uninstall will blow away your whole Twisted install when uninstalling a project shipping Twisted plugins that was installed with pip install. This really sounds like a bug in pip; top_level.txt is not a replacement for a proper uninstall log. So, how should Twisted and Twisted-related projects be packaged in order to avoid these issues? Please bear in mind that the current plugin system in Twisted was first introduced around March 2005 (replacing the even older plugin system in use at the time, I believe), thus there are quite a number of users relying on this code; any changes would need to be backwards-compatible to avoid causing problems for all of the existing projects and users relying on the functionality. I think you've answered your own question here: there *isn't* any way to package Twisted-related projects in a way that avoids the issue, due to the bug in pip. It's not Twisted's fault that pip takes shortcuts here. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Twisted plugin system and Python packaging
At 11:32 PM 9/24/2011 -0400, Glyph Lefkowitz wrote: On Sep 24, 2011, at 11:01 PM, P.J. Eby wrote: This really sounds like a bug in pip; top_level.txt is not a replacement for a proper uninstall log. Thanks. It appears that Pip's maintainers are (the teensiest bit grudgingly) coming around to this perspective as well: https://github.com/pypa/pip/issues/355#issuecomment-2182951https://github.com/pypa/pip/issues/355#issuecomment-2182951 You may want to note that Twisted isn't the only distribution that ships partial packages that aren't namespace packages. The logilabs packages are (or at any rate were) distributed this way, with a top-level package in one distribution, and some modules (without an __init__) were shipped in other distributions. (I could be wrong, but I think the mx.* stuff works this way, too.) (These are all packages that are distutils-only, though, or have their own extensions, IIRC.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Where can I found the meaning of .pth, .-nspkg.pth, .egg-info, .egg-link extensions files of site-package directory ?
At 04:41 PM 8/30/2011 +0200, Stéphane Klein wrote: Hi, where can I found the meaning of all this extensions of site-packages/ folder files : * .pth ? * .-nspkg.pth ? * .egg-info ? * .egg-link ? All except nspkg.pth can be found at: http://peak.telecommunity.com/DevCenter/EggFormats ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Safe Project Names and underscores in Project Names issue
At 08:02 PM 8/4/2011 -0700, Michael wrote: Forgive me if I ask a stupid question but what characters are allowed in a project name on PyPI and by Distribute/Setuptools? Setuptools allows names that have been processed through safe_name. As such, modifying the safe_name method to recognize undescore breaks pip. Why are you modifying the safe_name function? If you change it, it'll no longer be safe. ;-) Doing pip install pyramid_beaker installs the package successfully however any package tools (i.e pip) report the project as pyramid-beaker and as such becomes unusable name if PyPI is queried via RPC Interfaces. Trying to turn all the dashes back underscores breaks packages that have underscores in them (i.e. sphinxcontrib-programoutput). And if the package were to use both, it would be impossible to determine what it is without running all the permutations. I would appreciate if any one could advise me on this matter and let me know if this is a bug underscore treatment with Distribute/Setuptools, pip or PyPI. It's a PyPI incompatibility - neither the distutils nor PyPI were originally designed for a world involving automatically-resolved dependencies, where names needed to be unambiguous. That is, PyPI and distutils had an implicit assumption that 1) people would choose reasonable names and 2) be able to handle it when other people didn't. Setuptools, on the other hand, needs unambiguous naming, and therefore has a canonicalization algorithm that's designed to work reasonably well with distutils' file naming conventions. Distutils normally uses '-' to separate name parts in a filename, and (sometimes) escapes '-' using '_'. So setuptools canonicalizes all punctuation to '-', and escapes it as '_'. Some of PyPI's code has been changed to work with this approach, and some has not. [pyramid-beaker does not exist on PyPI, since its pyramid_beaker) From setuptools POV, the package name is pyramid-beaker, because '_' is reserved for escaping punctuation in filenames. If you want to look up a setuptools package name using PyPI XML-RPC, you can't always use the name directly; you may have to perform a PyPI search operation to obtain the package's PyPI name first. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Using `pkg_resources` without importing the module
At 09:25 PM 7/10/2011 +0200, cool-RR wrote: Hello, I want to use `pkg_resources` to retrieve an image file from a Python package. But I want to do this without importing the actual package. Is this possible using `pkg_resources`, or does it import the package? It imports the package, as it needs to know what loader object was used, to know whether it will be reading from a zipfile or whatever else. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Using `pkg_resources` without importing the module
At 12:38 AM 7/11/2011 +0200, cool-RR wrote: On Mon, Jul 11, 2011 at 12:33 AM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 09:25 PM 7/10/2011 +0200, cool-RR wrote: Hello, I want to use `pkg_resources` to retrieve an image file from a Python package. But I want to do this without importing the actual package. Is this possible using `pkg_resources`, or does it import the package? It imports the package, as it needs to know what loader object was used, to know whether it will be reading from a zipfile or whatever else. Hm. Are you familiar with any other method that can be used to get resources without importing? If you don't, then my next direction is to combine `pkg_resources` with my module-tasting technique; using an `__import__` hook to do a very minimialistic import of a module/package, without importing any other modules that it tries to import. Do you think that this minimalistic import will give `pkg_resources` enough data (about the loader or otherwise) to get the resources? Dunno. It looks for a __loader__ attribute, so that's got to be there. (Unless it's a normal filesystem package or module; that's the case where __loader__ is not normally set.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] does easy_install.py need to guess the site-packages path?
At 09:54 PM 6/7/2011 -0700, James wrote: On Tue, Jun 7, 2011 at 6:30 PM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 12:00 AM 6/7/2011 -0700, James wrote: As an example I'm looking at setuptools-0.6c11-py2.7.egg, can someone tell me why setuptools/command/east_install.py in get_site_dirs() does its own computation of where site-packages is? As of 2.7 there are already 4 separate places in the python where this path is computed. Maybe I'm missing something but I don't see why an egg would have an opinion on this matter. It doesn't do that in order to know where to install things; it does it to know what places are *safe* to install things that need .pth support. I'm seeing it make up the path and then fail in a copytree since the computed dest directory in my case doesn't exist So I'm not exactly sure what you mean when you say it doesn't. Unless you override it, easy_install asks the distutils where to install things. So, the made up path you're referring to came from the distutils. (Which has yet *another* set of code to generate the path(s)!) If you set DISTUTILS_DEBUG=yes in your environment variables, and run the easy_install again, you'll see exactly where every setting comes from. The output of get_site_dirs() is *not* used to determine the installation path, only to *validate* it. (And unfortunately, there is no way to obtain this list from the site module directly.) I guess that is the nub, oh well. cheers, - James ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] does easy_install.py need to guess the site-packages path?
At 12:00 AM 6/7/2011 -0700, James wrote: As an example I'm looking at setuptools-0.6c11-py2.7.egg, can someone tell me why setuptools/command/east_install.py in get_site_dirs() does its own computation of where site-packages is? As of 2.7 there are already 4 separate places in the python where this path is computed. Maybe I'm missing something but I don't see why an egg would have an opinion on this matter. It doesn't do that in order to know where to install things; it does it to know what places are *safe* to install things that need .pth support. (And unfortunately, there is no way to obtain this list from the site module directly.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] windows setuptools.exe
At 11:21 PM 5/30/2011 -0700, James wrote: Didn't see any not-so-easy how to build/install this on x64 notes either. Can someone point me to that if there is such a thing? If there is no such thing can someone please let me out of my misery? I've updated the PyPI page to note the problem prominently under the Windows instructions, and included a workaround. Sorry for the inconvenience. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute's sandboxing doesn't preserve working_set; leads to setup_requires problems
At 11:28 AM 5/22/2011 -0700, chiggsy wrote: Are people still using setuptools? Yes. Over the last 9 hours alone, the 0.6 development snapshot version (0.6c12dev_r88795) was downloaded from over 100 unique IPs. They most likely represent people manually upgrading to the latest version, since the user agents are mostly older setuptools versions, like 0.6c5, 0.6c9 and 0.6c11. I thought that distribute was the new way forward...? Not really. Unless you're using Python 3, or you want different default options from setuptools, there's little advantage to using distribute. (It also includes bugs that setuptools does not.) In addition, the announced direction of distribute is that they're replacing it with the new packaging project, formerly known as distutils2. Which means, again, that outside of Python 3, there's no compelling reason to switch; you might as well wait for packaging to roll around. So, all the hype was pretty much just that: hype and FUD-slinging. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute's sandboxing doesn't preserve working_set; leads to setup_requires problems
At 04:10 PM 5/19/2011 -0400, Erik Bray wrote: Hello all, I've got a tricky problem I'm trying to deal with. Here's the scenario: I'm trying to build a package that has two requirements in setup_requires; let's say `setup_requires = ['package_A', 'package_B']`. The problem is that package_B also contains package_A in its own setup_requires. What happens when I do an install/build is that package_B is downloaded and installed--in the process it also downloads and installs package_A in its sandbox. This wouldn't be a problem except that the sandboxed temp install of package_A is left in pkg_resources.working_set.entries, and so it's assumed package_A is already installed, and the main install doesn't try to fetch it. However, when it goes to import from package_A, I get an import error (because the sandbox it was installed in has since been deleted). If I reverse the order it doesn't work either for a different, but related problem. package_A gets installed into the cwd and is added to pkg_resources.working_set. When package_B is installed it uses the existing package_A installation, so that's fine. But then, due to some complicated interplay, package_A never gets added to sys.path. I'd consider this a defect, though I'm wondering if there's something I could do differently to avoid this situation. One such workaround would be to use setuptools, since I fixed this bug a couple of years ago. (Apparently, the fix still hasn't made it to Distribute.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute's sandboxing doesn't preserve working_set; leads to setup_requires problems
At 04:35 PM 5/19/2011 -0400, Erik Bray wrote:
Just to confirm my theory about this, I modified
setuptools.sandbox.run_setup to also save off and restore
pkg_resources.working_set.{entries,entry_keys,by_key}. This solves
the problem, and the build works regardless of how my setup_requires
are ordered. Is there any reason this shouldn't be done? It seems
reasonable to me... It would also still be nice to find a workaround
until and unless this gets patched.
That's necessary, but I don't think it's sufficient. The changes I
did to fix this in 2009 save other aspects of pkg_resources state
besides just those, and I don't think it's something you can fix by
monkeypatching.
(I could be wrong, of course, but given that setuptools was already
been fixed, I'm not that motivated to investigate more deeply.)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
At 10:29 AM 5/12/2011 -0400, Jim Fulton wrote: On Thu, May 12, 2011 at 10:09 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: ... - stop adding features so distutils2/packaging slowly takes over Absolutely. I couldn't agree more. Just understand that we're going to have to support old packages that import setuptools in their setup scripts indefinitely. That's one of the biggest challenges I see. Maybe packaging can (does?) provide a shim for this. As I said earlier, we do have backward compat in everything we do with packages. That leads to ugly code in some places, but we have to. But as you said, there's the maturity problem... OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. You should be aware of a few things going forward, with respect to compatibility. While Distribute includes many changes that are not in setuptools; the reverse is also true: setuptools includes bug fixes that are not currently fixed in Distribute. One important fix is rather complex, as there was a problem with build-time dependency recursion that manifested itself as multiple bug reports for multiple packages. This was fixed in setuptools, but the Distribute developers opted not to port the fix when it first came out a year or two ago, and AFAIK that has not changed. So, you should be aware that you may have some non-trivial merge work ahead, if you want to include those fixes into Distribute. In addition, Distribute contains various pieces of anti-setuptools code, in the sense that it deliberately attempts to prevent setuptools being installed or updated. I don't know if you care about that one way or the other, but you should be aware that it exists. (And of course, there is 2to3.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools + specifying project's version
At 03:29 PM 5/9/2011 -0400, Ruslan Spivak wrote:
Hi,
In
http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
there is a statement that 2.1-rc2 means you've already released 2.1
and an example
parse_version('2.1-rc2') parse_version('2.1')
False
Running the example gives quite the opposite result (setuptools-0.6c11):
parse_version('2.1-rc2') parse_version('2.1')
True
and actually it turns out that a pre-release tag 2.1rc2 is equal to
the post-release tag 2.1-rc2
parse_version('2.1-rc2') == parse_version('2.1rc2')
True
Does anyone have any idea why that's the case or is it a bug?
If it's a bug, it's a documentation bug. Originally, setuptools had
the behavior described, and I later realized it was a bad idea. ;-)
I think I skipped updating the documentation at the time, though,
because there were still versions of setuptools in the field which
could confuse the two, and thus using a '-' would still be a bad practice.
It might be a good idea to update it *now*, though. ;-)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] dependencies, pip and non-PyPI-hosted packages
At 04:54 PM 4/22/2011 -0500, Carl Meyer wrote: No, it is calling the distribute setup. If you look at how your package is installed, you'll find it in an egg - that's a sure sign of setuptools/distribute. It's just that python setup.py install does not handle dependencies, even with setuptools/distribute. Uh, yes it does, actually. (At least with setuptools, it does; don't know about distribute.) Ernesto, does it work with the official setuptools? (i.e., if you completely uninstall distribute and install setuptools instead) If it doesn't work, you can file a bug at http://bugs.python.org/setuptools and I'll see what we can do to get your project fixed up. (Just make sure you've *fully* uninstalled Distribute, and use ez_setup.py instead of distribute_setup.py, as Distribute does some patching that keeps setuptools from installing correctly.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Including symlinked data files in an egg
At 06:00 PM 4/21/2011 +0200, Ãric Araujo wrote: Note that if you include files such as your test, one or more files or diffs is preferred to binary archives.) Note that since the issue is symlink support, uploading one or more files rather than an archive won't work. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Including symlinked data files in an egg
At 10:56 AM 4/20/2011 +0200, Wichert Akkerman wrote: On 12/16/10 00:52 , P.J. Eby wrote: At 04:18 PM 12/15/2010 +0100, Wichert Akkerman wrote: On 12/15/10 16:15 , P.J. Eby wrote: Most likely, the problem is with the file finder being used. Are you using a git plugin for setuptools, or simply listing everything in MANIFEST.in? If the former, it may be that the git plugin you're using simply doesn't support symlinks. If you're not using a git plugin, perhaps there is something amiss in the MANIFEST.in, and setuptools' built-in support for subversion is hiding the problem by picking up the symlinks. I am not using a git (or other) plugin. I tried listing things in MANIFEST.in, for example using: graft my/package/templates/ graft my/package/templates/libraries unfortunately that had no effect: libraries was not included, not as symlink nor as a copy of the symlink target. I don't know whether MANIFEST.in is supposed to support symlinks or not, but the fact that it's working with subversion is strongly indicative that setuptools' file finder is picking up stuff that MANIFEST.in is not. I don't know *why* MANIFEST.in wouldn't pick up symlinks, though. Perhaps you could try boiling this down to a simpler test case (e.g., subversion and git versions of the same minimal package containing only a symlink referred to by MANIFEST.in) so we can narrow it down some more? I've finally gotten around to doing this. I have attached test.tar.gz with a minimal package that demonstrates this. Ah. It appears MANIFEST.in simply doesn't support symlinks. (Distutils has explicit code to filter them out, in fact.) This is a distutils issue, which setuptools can't do anything about. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Including symlinked data files in an egg
At 08:12 PM 4/20/2011 +0200, Wichert Akkerman wrote: Is there another way to get this working? I'ld hate to have to resort to monkeypatching distutils. Well, you could have the symlinks go the other way around, I suppose. ;-) Alternately, you could write a file finder plugin for setuptools, or see whether one of the git plugins for setuptools fixes the problem. (Note: the plugin would only be needed when building from a direct git checkout - building from an sdist (source .tar.gz or .zip) will not need it.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] DRAFT PEP 396 - module version number
At 10:31 AM 4/5/2011 -0400, Barry Warsaw wrote: On Mar 25, 2011, at 03:52 AM, Ãric Araujo wrote: I am not sure we should advertise setuptools namespace packages, given that standardization is under way (PEP 382). On one hand it would be childish not to acknowledge that setuptools is widely used, on the other hand in this particular time and place I think we should wait for official namespace packages to be implemented and talk about those. Just as an FYI, official namespace packages have existed since Python 2.3; they are implemented using pkgutil.extend_path() -- added, IIRC, back when Guido and Barry were both working at Zope Corp. ;-) Setuptools and PEP 382 are simply enhanced implementations of the concept. #. For modules which live inside a namespace package, the sub-package name SHOULD include the ``__version__`` attribute. I think this works with both setuptools and PEP 382 namespace packages, which is nice (see above questioning). The namespace module itself SHOULD NOT include its own ``__version__`` attribute. I guess this makes sense for setuptools namespace packages, but from my understanding of PEP 382, it is possible to have a Python package that is a namespace package and has submodules. (I hope Martin will correct me if needed.) This thing (âportionâ in PEP 382 lingo) should be allowed to declare a version IMO. Agreed, if that is true. I kind of hope it's *not* true though! Anyway, this is a SHOULD NOT not MUST NOT so I think it's safe. In principle, if you simply *must* have a non-empty __init__ module in a namespace package, and you really need to have a __version__ of that, then I suppose its __version__ should match the version of the project that supplies it. But yeah, I think it should still be considered a poor practice to put stuff in a namespace's __init__, even if/when PEP 382 makes it practical to implement non-empty __init__'s. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools download error?
At 10:05 PM 4/3/2011 +0200, Reinout van Rees wrote: Hi, My setuptools-using colleagues have problems with downloading setuptools. Initially I suspected the 0.6c12-r12345something releases, that old release numbers were disappearing. But that's apparently not the case, even though having such version numbers downloaded by a standard buildout bootstrap worries me a bit. I tried using wget to download one such release and it also failed. It would download 95% of the file and then stall... Pinning setuptools to 06c11 (the latest stable) worked like a charm: that one downloaded just fine (or was already available in the cache, probably). Is there something wrong with the peak server? Should I fix something on our end? (I'm using distribute myself, so I don't have this problem). You're not the only one who has reported this problem, but I've never been able to reproduce it. I have no clue what's going on, unless it's a matter of what time of day it works vs. not. It's a bog-standard Apache server serving a simple file, so I have no clue what would make it stick like that. Suggestions welcome. (If all else fails, remember that the dev snapshots are pulled from svn.python.org... so you can actually use a svn url instead.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv, take two
At 02:14 PM 4/1/2011 -0400, Carl Meyer wrote: But, as I mentioned, the fact that easy_install itself relies on finding site-packages relative to sys.prefix forces the issue - easy_install (including existing versions of it) needs to just work. No, it doesn't, actually. easy_install only uses sys.prefix to identify site directories without having to test them. Its install paths actually come from the distutils -- so as long as the distutils install command has the right defaults, easy_install will work just fine. (Assuming sys.executable is correct.) What easy_install does if it's asked to install to a directory that: 1) doesn't look like a site directory (based on sys.prefix), and 2) isn't listed in --site-dirs on the command line or in the config files, is that it runs a test (using sys.executable) to see if .pth files are actually supported in that directory. So, if sys.prefix leads it to believe that the distutils-supplied target directory isn't really a site directory, it checks for itself whether it functions as a site directory. In other words, easy_install will run a bit slower in such a scenario (due to the extra time taken to test), but still function correctly. To stop it taking the extra time for the test, an additional command line option or configuration file option can be given. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv, take two
At 01:35 PM 3/30/2011 -0400, Carl Meyer wrote: So... it seems to me that we're likely to break _some_ third-party code using sys.prefix regardless of what we do here. My instinct says adding sys.virtual_prefix and leaving sys.prefix alone is the better approach, but I'm not very firmly entrenched in that position. Looking at it from a software distribution POV, I would say that the virtual prefix is what it should point to, since that means things won't get installed to the wrong place. (Of course, a configuration option could be used to override it, if really necessary.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buildout, setuptools, sourceforge problems
At 04:25 PM 3/29/2011 -0400, Jeff Kunce wrote: There seem to be some problems with packages on sourceforge not working with buildout. Something about sourceforge is sending two content-length headers. Update your setuptools to 0.6c12dev-r88975 for the fix. (If you're using a forked setuptoools, you'll need to uninstall it first so it doesn't block your update.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install doesn't work when there are multiple Content-Length headers
At 10:08 PM 3/28/2011 +0700, Hoang Xuan Phu wrote: Hi all, Just today I'm using easy_install to install mechanize and it is failing with the error ValueError: invalid literal for int() with base 10: '382727, 382727'. By reading the source code and looking at the headers I see that the server is returning 2 Content-Length headers (same value, 382727), which is turned into '382727, 382727'. Fixing this should be very easy and I can do it then submit a patch. I'm just wondering, as distutils seem to be in a forking process, what's the best way to solve this? easy_install -U setuptools will update you to a version that fixes this, as I've already checked in a fix. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv, take two
At 02:44 PM 3/18/2011 -0400, Carl Meyer wrote: Apparently (I am Windows-ignorant) recent Windows versions do support symlinks? Technically, some Windows filesystems can support this. In practice, no user-visible tools actually support making or using them sanely, AFAIK. So, I suggest promoting symlinks as the standard way, with binary-copying being a Windows-only workaround. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python
At 01:41 PM 3/17/2011 -0400, Carl Meyer wrote: Actually, now that I come to think of it, pythonv (take two) does already cover your requirement. If you have a symlinked or copied python binary, and an empty pythonv.conf one directory up, Is there any reason why the configuration file has to be one directory up, intead of adjacent to the executable? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python
At 05:13 PM 3/17/2011 -0400, Jim Fulton wrote: I suggest the following: Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'. So if I've linked the Python executable to ./bin/clean, look for ./bin/clean.pythonv and ./pythonv.cfg. And on Windows, presumably remove the .exe part? or are you saying 'python.exe.pythonv'? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python
At 07:53 PM 3/17/2011 -0400, Carl Meyer wrote: FWIW, I've pushed a reworking of the config-file-finding, with the following shed-paint color choices: * File is named executable-name.virtual.conf (I kept the .virtual, despite it being longer and not strictly necessary, because I think it more clearly expresses the function of the file. The existence or absence of this file changes Python's behavior significantly, so I think its name should be quite explicit.) * executable-name has the extension stripped on Windows, but not otherwise. This combination should work well on Windows, where the default explorer settings will show e.g. 'python.virtual' next to 'python' in the directory. (Windows strips suffixes from display by default, and moves them to a type column.) * I eliminated any form of generically-named config file, as I think the extra possible names (and thus possible sources of confusion) is not really worth the benefit. The only use case I can think of is if you have multiple python binaries or symlinks next to each other and want them all to use the same virtual config - and I can't really think why you'd want multiple binaries in that case. The main reason I'd use differently-named binaries would be if I were shipping multiple runnable applications that I wanted to look to users like true .exe's. I don't see a reason why I wouldn't use separate .virtual.conf files, though, especially if their contents are minimal. (Awesomeness bonus: if the executable put *itself* on sys.path, and ran __main__, you could simply tack a zipfile on the end of the .exe and have a ready-to-run application.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] window 64bit madness
At 11:28 AM 3/16/2011 +0100, Adam GROSZER wrote: On 03/14/2011 07:50 PM, P.J. Eby wrote: Run python -c 'import pkg_resources;print pkg_resources.get_build_platform()' (with the Python interpreter you're using. D:\installc:\Python26_64\python.exe Python 2.6.6 (r266:84297, Aug 24 2010, 18:13:38) [MSC v.1500 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import pkg_resources;print pkg_resources.get_build_platform() win-amd64 Hm. What's sys.platform? Is it win32? I suspect the problem has to do with all the win32-specificness scattered through setuptools; I think I know what I need to do to fix it all, but it'll be a fairly substantial patch; can you help with the testing if I email you such a patch? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] window 64bit madness
At 03:40 PM 3/14/2011 +0100, Adam GROSZER wrote: Hello, Having problems here installing http://pypi.python.org/packages/2.6/r/reportlab/reportlab-2.5.win-amd64-py2.6.exe . Neither setuptools 0.6c11 nor distribute 0.6.14 gets it right. We don't have and don't want to have a compiler on the server, so we need rely on binary packages. - setuptools just fails miserably even with easy_install: http://paste.lisp.org/+2KZD - distribute installs it (tho in a ...-win32.egg folder): http://paste.lisp.org/+2KZE - zc.buildout cannot install it with distribute, because it wants to use the source tarball (and we don't have a compiler) or when I make it not to be able to see the tarball, it does not find the reportlab-2.5.win-amd64-py2.6.exe. I guess it does not get the platform right. Any hints? Run python -c 'import pkg_resources;print pkg_resources.get_build_platform()' (with the Python interpreter you're using. (By the way, I think from the log you gave, that reportlab may in fact be installed and usable on your machine, despite the attempt to download it a second time and build it from source. But I could be wrong.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 08:08 AM 3/10/2011 -0500, Jim Fulton wrote: I really should let this rest ... really I notice you seem to have already let rest defending your proposal, as opposed to opposing mine. ;-) That is, I don't see where you've included any counterargument for why convincing people to *stop* using package for python package isn't going to be a lot harder than simply *adding* the term project to existing docs, via simple explanations like this one: If you would like to distribute your python package or module, you need to create a project. A project consists of a directory containing the package(s) or module(s) you want to distribute, along with a setup.py/.cfg, specifying the project's name, current version number, and other information. If you wish to distribute your package via PyPI, then you must choose a unique project name and register it. If you are only distributing one module or package, you can name the project after it, as long as it doesn't conflict with any other project names already registered on PyPI. Context-specific explanations like this are easy to give, at a place where the recipient of the explanation *wants* to learn something. In contrast, to convince everybody in the world to replace package with module, you must send out a constant broadcast to people who don't really care. (your other points are addressed below) On Wed, Mar 9, 2011 at 11:43 AM, P.J. Eby p...@telecommunity.com wrote: At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Sourceforge hosts projects. Freshmeat indexes projects. Mozdev.org hosts projects. The Apache Foundation hosts projects. Project, IOW, is *exactly* the word people use for these things, in the larger world of software, and that's precisely why I chose it for my original terminology proposal. But the things in PyPI are not projects. Projects have bug trackers, and mailing lists, and source code repositories. And which of those things have to be hosted on the same site as the project's index page? Freshmeat, for example, is not a project *hosting* system, it's a project *index*. PyPI is in that sense, a project index. Some index pages may link to all the stuff associated with that project, some may not. (i.e. the set of all possible project features is not equal to the intersection of all projects' actual features: some project have mailing lists and not bug trackers, and vice versa. This does not make them non-projects.) Projects are organizations of people -- not software distributions. I'm an organization of people; am I a project? No, the various things I have listed on PyPI are my projects, and I distribute releases of them. The things in PyPI that you call projects are things that get produced by projects. There isn't a buildout.recipe.egg project. buildout.recipe.egg is just a um packaging of some software components. It's not a project in any usual sense of the word. I don't get that. You work on it, and it is distinct from other works. That makes it a project. No. End users need to know about this. They need to know what these names mean and that the package name (distutils) or project name (setuptools) doesn't imply that the distribution will provide a python package of the same name. Trust me on this. Users care about this. Actually, I believe distutils calls it a distribution name, but I could be wrong about that. ;-) For one thing, if the distutils documentation simply starts out like: If you want to distribute your work to the larger Python community, you need to create a project for it. In practical terms, this means having a directory with a setup.py and the code, data, or documentation you wish to distribute. Your project will also need a unique name, if you want to make it accessible to others via the Python Project Index (PyPI). (replace setup.py w/setup.cfg for distutils2, of course) It does? Where? Can you give a link? I don't see this text anywhere. Of course not; it was a proposal for a hypothetical introduction. That's why it says if up there. ;-) This usage of project also maps onto common IDE usage of the term project -- a directory of stuff that you're going to edit and build. That use of project is equivalent to working directory and not relevant, IMO. Huh? In an IDE, a project is a thing you build and distribute, usually with source control. It's distinct from other projects, and it has a name. It is usually not tied to a specific code unit such as a module or package (regardless of what the code units of the relevant programming language are called). It has additional metadata, over and above the actual code units, and possibly includes non-code resources such as documentation, data, images, etc. IOW, it's *exactly* the sort of project we're talking about here. So, the term project
Re: [Distutils] Name the software! Package quality tester.
At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Sourceforge hosts projects. Freshmeat indexes projects. Mozdev.org hosts projects. The Apache Foundation hosts projects. Project, IOW, is *exactly* the word people use for these things, in the larger world of software, and that's precisely why I chose it for my original terminology proposal. Many PyPI listings also only describe a project, in the sense that there is no release information at all, or the code is only available via a revision control system, etc. The term project has has never stuck, despite being discussed repeatedly. It's only been discussed here, on this list. It hasn't been put in official documentation, or really blessed by anybody. When it has been discussed, it's been considered a reasonable name, and when people have needed to make the distinction, they've tended to use it. The primary reason it hasn't caught on in a larger sense is that people don't know about it, and have no motivation to learn it unless they end up in a situation where the distinction makes a difference... And let's face it, it really only makes a difference if you are creating some kind of packaging or distribution tool, or if you have a corner case of using one. I think given the historical use of the term package it was reasonable to find another term. OK, we tried. It didn't work. I don't think that's an accurate assessment on two points. First, we didn't try -- *I* did. (It's possible that someone else has promoted it, but I don't recall any instances of that.) So, there actually being a we behind it -- where we includes an approved PEP, documentation, etc., would be helpful. Second, I don't think it's accurate to say it didn't work. It's not like people who need the distinction have objected to the word or proposed any alternatives. We can pretent that if we work hard enough, we can make people adopt our confusing terminology. Good luck with that. No matter which way we go (assuming there aren't any other alternatives), we will be trying to get some group of people to change their terminology. I'm just pointing out that the group that would need to change to use project is both smaller *and* inherently more motivated to change their usage, than the group that would need to replace package with module. Thus, if getting people to use project is an uphill battle, getting people to stop using package is going to be a much higher vertical cliff. ;-) For one thing, if the distutils documentation simply starts out like: If you want to distribute your work to the larger Python community, you need to create a project for it. In practical terms, this means having a directory with a setup.py and the code, data, or documentation you wish to distribute. Your project will also need a unique name, if you want to make it accessible to others via the Python Project Index (PyPI). (replace setup.py w/setup.cfg for distutils2, of course) This usage of project also maps onto common IDE usage of the term project -- a directory of stuff that you're going to edit and build. And, it immediately introduces the term to a superset of the audience that will need to know it. Having PyPI describe its contents as projects is pretty much the other half of the indoctrination needed. In contrast, to make the package-module change, you'd have to not only change the official language reference and tutorial, but also every third-party book or tutorial about Python. Sure, some of those third party references would also exist for package as project, but that's simply an *imprecise* usage, rather than an *incorrect* one. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 10:22 PM 3/9/2011 -0500, Martin v. Löwis wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Maybe we have lost the context here, but I think I agree with Jim. Even though PyPI hosts projects, they (the files you download) aren't projects - they are distributions or packages. I think you have lost the context; here, project refers to the thing that you have versions of, which distributions in turn are discrete manifestations of. That is, a project has releases which has distributions. For example, http://pypi.python.org/pypi/Trac is a PyPI page for a project, http://pypi.python.org/pypi/Trac/0.12.2 is the PyPI page for release 0.12.2 of that project, and http://pypi.python.org/packages/source/T/Trac/Trac-0.12.2.tar.gz is one of the distributions available for that release of that project. PyPI allows one to host a project that has neither releases nor distributions, so in that sense it is certainly an index of projects, in much the same way that ASF, SourceForge, MozDev, and others are. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 05:18 PM 3/7/2011 -0500, Jim Fulton wrote: If what we now call packages were called modules, then we could start using the term package the way everyone else does. I think lots of people would be less confused. It seems to me that in order to make that change, you have to get more people to change their terminology, since the set of people who need to refer to package[module] is larger than the set of people who need to refer to package[project]. (There is also a larger body of documentation associated with package[module].) IOW, I think this proposal is a heavy uphill battle, both in the number of people to be convinced and the amount of documentation. In addition, the people who are calling a project a package can more easily understand the need to call it a project, than the people who are calling a package a package, will understand the need to call it a module. ;-) Otherwise, I prefer we try hard to use the precise definitions above. This topic can be confusing enough without making it more so through sloppy terminology. I think that this approach is more achievable: it requires only an official blessing, a relatively small amount of documentation to be changed, and the renaming of PyPI et al. (i.e. Python Projects Index, projects.python.org, etc.) (Projects Index is a better name anyway, since some things on PyPI are not packages at all but applications, scripts, modules, plugins, etc.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install installing beta version of psycopg2
At 12:41 PM 2/18/2011 +, Daniele Varrazzo wrote: I've tried to be good and replace the download_url, which used to refer to a directory containing all the packages, to a direct link to the package to download (see http://pypi.python.org/pypi/psycopg2/2.3.2). It wasn't enough as probably previous versions listed in /simple/ still refer to the directory (see http://pypi.python.org/simple/psycopg2/). Is there a way to clean the list in /simple/, apart from deleting all the previous releases from PyPI, which would be a net loss for PyPI as a repository? Yes. Just edit those releases. Log in to PyPI, go to your package page, then click on Releases. There will be an edit link for each release. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install installing beta version of psycopg2
At 12:01 AM 2/17/2011 +, Daniele Varrazzo wrote: On Wed, Feb 16, 2011 at 8:40 PM, P.J. Eby p...@telecommunity.com wrote: At 05:47 PM 2/16/2011 +, Daniele Varrazzo wrote: Do I, as a packager, have the possibility to say what I have specified on PyPI as stable release is exactly what I mean? If you don't want easy_install to find it, don't list it on the pages referred to in your Home Page or Download URL on PyPI. Easy_install reads those pages because many package authors do not provide directly usable URLs or packages on PyPI. I'm sorry, it is obvious that I have not spent so much time into this problem as the designer of this feature. But it still don't get the rationale behind discarding available, non-ambiguous metadata in favour of screen scraping. When easy_install was first written, PyPI didn't even support *uploading*. And the quality of available metadata on PyPI is still quite sketchy -- many packages will have only one file uploaded for an outdated version, but still have good downloads on their home pages or download URLs. While I realize this can be an inconvenience for the people who DO have good metadata, the truth is that there are many packages for which unstable version numbers are in fact the *best* download choice for many users. Without a uniform versioning system that *every* package adheres to (and PEP 386 isn't actually sufficient for this yet -- something more like semantic versioning is needed), there's no way to easily set a policy across projects for how stable a version do you want to download? In general, the practice for most projects is to simply publish unstable, don't download this unless you really mean it versions via development links, such as links to svn or other repositories. These links don't look like downloads to easy_install, except for the #egg=project-version tag that tells it how to interpret them, and saying '#egg=myproject-beta' suffices to ensure that only a specific installation request for 'myproject==beta' will follow the link. (Unfortunately, this tag does *not* currently override easy_install's native interpretation of the link, so tacking '#egg=psycopg-beta' on the end of your download links won't stop them being detected as future versions. See below for other workarounds.) I don't think it is fair to ask to stop listing the beta from the homepage and the download page of the 2-pages website of the module: how should I advertise there is a beta around and testing is welcome? You can make a direct download link, or make the filename not one that easy_install will recognize. For example, if you rename the downloads to beta-psycopg-whatever.*, or use a URL that redirects, like /beta-download, that's then redirected by the web server to the appropriate file location. easy_install only looks at links that *appear* to be distutils-or-setuptools-generated archives for the desired project. Another alternative is to block easy_install from parsing your home page or download links, by simply providing those links inline in your PyPI project description, and *removing* the specific fields from the current release and all previous releases stored on PyPI. Still another would be to block the 'setuptools' and 'distribute' user agents from your website, returning 404s. the shortcomings of a package manager Well, technically, this'd be a feature. Granted, it's only a feature for users of projects whose maintainers are *not* keeping a well-groomed PyPI page. ;-) I guess it is a shortcoming in the sense that there ought to be a way to stop it from using this feature. In retrospect, the #egg=proj-ver feature should override easy_install's native interpretation of a URL, rather than just adding to it, and I think I would be justified in considering this a bug worthy of fixing. Unfortunately, even if I fixed that today, it wouldn't have ANY effect on 99% of the field installations of any Python package management tools: there are still people using 4 or 5 year old versions of easy_install, and a lot of people use Distribute (via their OS install), which is a year behind the setuptools trunk on various things. Most other Python package management solutions are based on top of easy_install in one way or another, as well. Pip is the main package manager that uses its own link-finding algorithm, but it only supports source installation AFAIK. Distutils2 uses a link-finding algorithm that was lifted pretty much verbatim from easy_install, though I think there may have been some additions to it since I last looked at it. You can prevent this as a package author, by specifying zip_safe=False in your setup() script. psycopg2 is not zip_safe, as it contains a C extension. C extensions don't make a package not-zip-safe - they just mean that if you install it zipped, there has to be an egg cache. The cache is used to unzip the C extension. If you want to force
Re: [Distutils] easy_install installing beta version of psycopg2
At 05:47 PM 2/16/2011 +, Daniele Varrazzo wrote: Do I, as a packager, have the possibility to say what I have specified on PyPI as stable release is exactly what I mean? If you don't want easy_install to find it, don't list it on the pages referred to in your Home Page or Download URL on PyPI. Easy_install reads those pages because many package authors do not provide directly usable URLs or packages on PyPI. possibly not requiring a writable egg cache (see You can prevent this as a package author, by specifying zip_safe=False in your setup() script. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] .exe for script in Windows doesn't work
At 03:47 PM 2/14/2011 +0200, cool-RR wrote: On Fri, Jan 14, 2011 at 3:01 AM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 10:45 PM 1/13/2011 +0100, Martin v. Löwis wrote: How is that generated (i.e. what piece of code specifically generates it)? See setuptools.command.install_scripts.run() - it makes .exe and -http://script.py/-script.pywscript.py/-script.pyw files. It has some hackery to detect bdist_wininst and use a relative #! line in that case, but it doesn't have equivalent hackery for bdist_msi. P.J., do you think it will suffice to patch Distribute here: https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34https://bitbucket.org/tarek/distribute/src/4ab9b96dc540/setuptools/command/install_scripts.py#cl-34 To detect bdist_msi as well? No. If it were that simple, I'd already have done it. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] .exe for script in Windows doesn't work
At 06:49 PM 2/14/2011 +0200, cool-RR wrote: So... Should I open a ticket on the Distribute project? If you like. But http://bugs.python.org/setuptools/issue112 already exists, and I believe the Distribute project still shadows setuptools' bug tracker. (I could be wrong about that.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Reading in Universal Newline mode with pkg_resources
At 08:37 PM 2/8/2011 +0200, cool-RR wrote:
Hello,
I'm accessing a text file using `pkg_resources`. I want to read it
in universal newline mode, i.e. to read newlines as '\n' regardless
whether they're actually '\r\n'. How do I do this?
Perhaps:
StringIO(resource_string('whatever','resource').replace('\r\n','\n'))
?
Or, this might be better, since I believe splitlines uses a true
Universal Newline approach:
StringIO('\n'.join(resource_string('whatever','resource').splitlines()))
The pkg_resources APIs are binary, rather than text, so you have to
do the necessary munging yourself, unless you use resource_filename()
and open the file directly (which has its own issues).
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [issue121] SVN credentials can't be provided to easy_install
If you do svn co svn://user:sec...@svn.example.com/repo/trunk/my-egg, does that work, or does it prompt you for the password? My guess is that svn itself is the problem here, because easy_install does not remove password information from the URL, it just passes the URL as-is to the svn command. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] namespace_packages: include itself ot not include
At 10:29 PM 2/8/2011 +0300, Roman Kurakin wrote: There is a package 'aaa.bbb' that uses setuptool only if it is installed on the system. In that case, it can't sensibly use setuptools namespace packages. At all. You need to either: 1. always use setuptools 2. use an alternate namespace package mechanism (such as pkgutil.extend_path()), and not declare the namespace 3. Not use namespace packages at all This is useful for development, but this breaks rpm build process cause it expects __init__.py and doesn't expect egg and pth, more over it ignores them. So in my case there is no egg pth. The nspkg.pth file is for non-egg installs. If you have an egg, there is no nspkg.pth file for that package. I started to dig if there is possibility to coexists development and rpmbuild processes on the same system without very messy spec file. I didn't find the strict requirements for the package to list itself in a namespace_package even if I know that there would be 'aaa.bbb.ccc'. It is a requirement for consistent and correct runtime behavior across all installation targets. (The installation targets are .egg file, .egg-directory, and non-egg (e.g. rpm)) So probably question does it break something if package 'aaa.bbb' wouldn't list itself in a namespace_package? And does it provide something useful if package 'aaa.bbb' would? To make sure we're clear: if aaa.bbb is actually a namespace -- that is, if it has separately-installable contents -- then you MUST declare it if you want consistently correct runtime behavior. If you do not declare it, then there are some environments where it will appear to work, and there will be other (superficially identical) environments where some part of the namespace will mysteriously fail to be importable. In other words, the rules are there for a reason. These limitations are the nature of Python 2.x's import machinery, which was not originally designed with namespace packages in mind. There is a namespace package PEP that (in principle) provides a better mechanism than what setuptools does, but implementation progress is currently stalled, and the PEP has not been accepted. So, your options at the present time for separately installed parts of a namespace package are as I have described. There is a pure distutils approach you can use that allows partially installed packages to exist, but it is somewhat fragile and is not setuptools compatible. It requires that there be a provider of a package, in the sense that exactly one project contains the __init__.py for the package. But it is fragile because it may not be supported on all platforms and build targets, and it requires that aaa.bbb be always installed before aaa.bbb.ccc but of course the distutils by themselves have no dependency mechanism to enforce this. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] namespace_packages: include itself ot not include
At 02:12 PM 2/4/2011 +0300, Roman Kurakin wrote: Hi, Let suppose that we have package aaa and subpackage bbb and we are going to write setup.py for bbb using setuptools: extra = dict( namespace_packages=[aaa, aaa.bbb], zip_safe = False, install_requires = ['setuptools'], ) if __name__==__main__: setup(name=aaa.bbb, version=0.0.1, description=Dummy example subpackage, author=Mr. Nemo, url=http://www.the.way.org/to/hell;, author_email=mrn...@the.way.org, packages=['aaa.bbb'], license='BSD', **extra) This is the way of namespace_packages usage I against of. So, the questions is am I right standing that package bbb, subpackage of aaa must list in namespace_packages only namespaces it participate in eq 'aaa', and must not list any namespaces it is provides, in this case 'aaa.bbb'? So correct value namespace_packages=['aaa'] in the case above. If 'aaa.bbb' is not itself a namespace package, then namespace_packages should only contain 'aaa'. And unless you will have yet another project which is installing something under aaa.bbb, then aaa.bbb does not need to be a namespace package. namespace_packages should only list namespaces in which the current project *participates*. That is, it should list packages that are *containers* for the thing(s) this project is providing, that are *shared* by other projects. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Python version in egg name
At 10:17 AM 2/3/2011 -0500, Matt Chaput wrote: When I create an egg the Python version used to create the egg is encoded in the egg filename, e.g. Whoosh-1.6.0-py2.7.egg. Is this version number used to decide what egg a user gets from PyPI? I didn't think it was, but a user is seeming to indicate that he got different versions based on what version of Python he was using. Is there a way to set this value to py2.5 as a configuration option, other than running setup.py using the Python 2.5 executable? Or not have it be part of the egg filename at all? I'm using Python 2.7 as my default Python install but I make sure that the code in my library is compatible with 2.5+. I've already someone think the library is only for a later version of Python because that's what I used to build the egg. Sorry if this is an old question, I looked around but didn't find any docs on the subject. I see you've already solved your issue by using source distributions, but for the archives I thought I should mention that the reason eggs are version specific is because they contained compiled .pyc or .pyo files, and those are only compatible with the Python version that compiled them. If you are distributing pure Python code through PyPI, though, there is usually no reason to ship it in an egg. Eggs were designed as a binary plugin format for rich application platforms, analagous to Java jars or Eclipse plugins. They're intended for scenarios where installing from source is overly complex and/or you want to make it so users can just drop a file into a plugin directory to get going. (easy_install came later, as a quick hack to automate building and installing eggs.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools and man pages
At 12:03 PM 1/25/2011 -0700, Andrew McNabb wrote:
I am maintaining a package that includes several scripts, and I recently
added a man page. Unfortunately, I was unable to figure out how to
specify the man page with setuptools. I ended up switching back to
vanilla distutils, which allowed me to specify the man page in setup.py:
data_files=[('man/man1', ['man/man1/pssh.1'])]
Is there an equivalent way to do this with setuptools? The closest
thing I could find in the setuptools documentation was, Note, by the
way, that this encapsulation of data files means that you can't actually
install data files to some arbitrary location on a user's machine; this
is a feature, not a bug. I appreciate the well-intended thought, but I
can't find any feature for specifying man pages. I don't want to
install to an arbitrary location, but I need to be able to install to
$PREFIX/man/man1).
Is there a way to do this with setuptools, or do I need to keep using
distutils? I would love to be able to use the console_scripts
feature, so it would be great if I could use setuptools, but obviously
the man pages are higher priority. I feel like I must be missing
something obvious. Thanks.
Setuptools has a distutils-compatible installation mode:
setup.py install --single-version-externally-managed --record=somefile
It's a bit awkward to type, but it should do what you want.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools and man pages
At 02:41 PM 1/25/2011 -0700, Andrew McNabb wrote: On Tue, Jan 25, 2011 at 03:10:09PM -0500, P.J. Eby wrote: Setuptools has a distutils-compatible installation mode: setup.py install --single-version-externally-managed --record=somefile It's a bit awkward to type, but it should do what you want. But wouldn't this require all end users to know the incantation? Well, those who want the man pages, certainly. ;-) Presumably I could add the following to the top of setup.py: sys.args += ['--single-version-externally-managed', '--record=somefile'] But that seems sort of dirty. :) It also won't do anything if they're installing via another tool such as pip, easy_install, buildout, etc. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools and man pages
At 03:53 PM 1/25/2011 -0700, Andrew McNabb wrote: On Tue, Jan 25, 2011 at 05:46:40PM -0500, P.J. Eby wrote: It also won't do anything if they're installing via another tool such as pip, easy_install, buildout, etc. Do each of those support some way to install man pages? I imagine one could write a buildout plugin that would do it. There was some discussion a while back about a buildout plugin for documentation. Really, distutils2 is probably a better candidate for solving this problem, but it's not yet released and in any case not widely installed as yet. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
At 01:55 PM 1/20/2011 +0800, Pherl Liu wrote: Hmm, I think it now only delete pkg_resource when pkg_resrouces.VersionConflict is caught, but the fix should be also delete pkg_resources when pkg_resources.DistributionNotFound is caught. Good catch. Under previous use cases, the only time you'd have pkg_resources and *not* setuptools, it would be if you were bundling pkg_resources. Nowadays, though, some distros split setuptools from pkg_resources, so you can have an older, distro-supplied pkg_resources, but no setuptools. Anyway, I've fixed this in SVN and on the website now. Thanks! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] current ez_setup.py appears to refers a non existing URL?
At 09:16 PM 1/20/2011 +0100, Jan-Wijbrand Kolman wrote: And indeed, when I download ez_setup.py myself: $ wget http://peak.telecommunity.com/dist/ez_setup.py and run it, I also get the 404 on the URL: When I made the changes earlier today, I accidentally pushed the 0.6c12 development version to /dist instead of the stable 0.6c12 version. It's fixed now; sorry about that. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
At 03:40 PM 1/19/2011 +0800, Pherl Liu wrote: Well.. I think I can fix this by editing ez_setup.py adding oneline after pkg_resources.DistributionNotFound is caught, in use_setuptools() del pkg_resources, sys.modules['pkg_resources'] Not sure if this makes sense. That's already in current versions of ez_setup.py; 0.6c9 is several years old. I'd suggest you use the svn externals to keep it up-to-date. See: http://peak.telecommunity.com/DevCenter/setuptools#managing-multiple-projects for details. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Bootstrap use_setuptools() in ez_setup.py failure
At 04:42 PM 1/12/2011 +0800, Pherl Liu wrote: Hi, I got some error messages when using ez_setup to download and use the easy_install. # setup.py from ez_setup import use_setuptools use_setuptools() from setuptools import setup setup(name = blabla, test_suite = some_test, namespace_package = [some_namespace], # many other options ) So I guess there might be some import problem in my machine (ubuntu lucid) that the pkg_resources.py cannot be loaded from the egg? Try running this script in your project directory: from ez_setup import use_setuptools use_setuptools() import sys, setuptools, pkg_resources print sys.path print pkg_resources.__file__ print setuptools.__file__ This should tell us what's going on with your import problem more specifically. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] .exe for script in Windows doesn't work
At 09:54 AM 1/13/2011 +0200, cool-RR wrote: On Thu, Jan 13, 2011 at 2:25 AM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 09:31 PM 1/12/2011 +0200, cool-RR wrote: Hi guys, I made a release of my project today, and now I see there's something wrong with it. When you install it on Windows using the windows binaries (that I made with `bdist_msi` under Python 2.7), the .exe scripts in the Scripts folder don't work. When you launch them, nothing happens. You can launch the associated *-script.pyw files and those *do* work. I investigated a little and possibly I figured it out. The shebang line says #!c:\Python27\pythonw.exe. This is the interpreter with which I *created* the binaries. But why should it be the interpreter with which the *user* works? The user could have c:\Python26\pythonw.exe as his interpreter or c:\Programs\Python25\pythonw.exe or g:\Pypy\pypy.exe as his interpreter. I tried editing the shebang line with notepad, and this caused the exe files to start working! (Of course this is not a real solution, I can't ask my users to do that.) Is this a bug in distribute? It's a limitation of setuptools+bdist_msi - when you build a bdist_wininst, setuptools writes a generic #! line, but when you build a bdist_msi, it doesn't realize you're building a distribution. So which project exactly is responsible for this limitation? Distribute? Setuptools. Do you think there's a good reason not to have the MSI put the path to python.exe itself into the shebang upon installation? I don't know how to have bdist_msi do that. Do you? As a quick workaround, you could try setting sys.executable to 'pythonw.exe' in your setup.py, *before* setuptools is imported, then build the .msi. I'd be reluctant to do that, since many users don't have the Python folder on their PATH, so it won't work for them at all. That's not how it works. When the #! line doesn't contain an absolute path, the .exe stub looks in the parent directory relative to where the script was installed. So, as long as the .exe and .pyw are in an immediate subdirectory of the Python directory (usually Scripts), it will work correctly. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] .exe for script in Windows doesn't work
At 10:45 PM 1/13/2011 +0100, Martin v. Löwis wrote: How is that generated (i.e. what piece of code specifically generates it)? See setuptools.command.install_scripts.run() - it makes .exe and -script.py/-script.pyw files. It has some hackery to detect bdist_wininst and use a relative #! line in that case, but it doesn't have equivalent hackery for bdist_msi. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] .exe for script in Windows doesn't work
At 09:31 PM 1/12/2011 +0200, cool-RR wrote: Hi guys, I made a release of my project today, and now I see there's something wrong with it. When you install it on Windows using the windows binaries (that I made with `bdist_msi` under Python 2.7), the .exe scripts in the Scripts folder don't work. When you launch them, nothing happens. You can launch the associated *-script.pyw files and those *do* work. I investigated a little and possibly I figured it out. The shebang line says #!c:\Python27\pythonw.exe. This is the interpreter with which I *created* the binaries. But why should it be the interpreter with which the *user* works? The user could have c:\Python26\pythonw.exe as his interpreter or c:\Programs\Python25\pythonw.exe or g:\Pypy\pypy.exe as his interpreter. I tried editing the shebang line with notepad, and this caused the exe files to start working! (Of course this is not a real solution, I can't ask my users to do that.) Is this a bug in distribute? It's a limitation of setuptools+bdist_msi - when you build a bdist_wininst, setuptools writes a generic #! line, but when you build a bdist_msi, it doesn't realize you're building a distribution. I'd appreciate if you can reply soon since I already started the release process and I don't want to confuse users. As a quick workaround, you could try setting sys.executable to 'pythonw.exe' in your setup.py, *before* setuptools is imported, then build the .msi. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [issue119] setuptools-0.6c11.win32-py2.5 python path recognition problem
At 05:39 AM 12/23/2010 +, hm wrote: I have downloaded setuptools-0.6c11.win32-py2.5.exe and tried to install it on Windows 7 (64 bit). I have an existing Python installation. The setuptool recognizes the path, however, puts a quote around the path. The problem is that it also carries the quotes around the Python path in the installation directory and makes a path like: C:\Python25\\Lib\site-packages\ This is an invalid path and in the next step the installer complains that cannot install the files in the provided path. The setuptool also does not allow editing this path. Any help is appreciated, asap. This sounds like a problem with the distutils installer for Windows. Have you tried installing any other Python .exe's from PyPI, and do they have the same problem? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] 'python setup.py test' in develop mode?
At 05:26 PM 12/17/2010 -0500, Barry Warsaw wrote:
Something bugs me about virtualenv, distribute, development, and testing. I
figure I'm probably doing something wrong and that y'all will be able to set
me straight.
I'm working on a new tool called pkgme[1]. It uses distribute and recommends
using virtualenv for development. After activating the virtualenv you can do
'python setup.py develop' and do convenient in-place editing so that your
changes to the source show up immediately in the running environment. So far
so good.
However, when I want to run the test suite, it does the equivalent of a
'python setup.py build' and then runs the tests out of the
build/lib.{platform}-{version} directory.
Really? That sounds wrong. python setup.py test should run the
tests against the *source* tree, with in-place extension builds.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Including symlinked data files in an egg
At 04:18 PM 12/15/2010 +0100, Wichert Akkerman wrote: On 12/15/10 16:15 , P.J. Eby wrote: Most likely, the problem is with the file finder being used. Are you using a git plugin for setuptools, or simply listing everything in MANIFEST.in? If the former, it may be that the git plugin you're using simply doesn't support symlinks. If you're not using a git plugin, perhaps there is something amiss in the MANIFEST.in, and setuptools' built-in support for subversion is hiding the problem by picking up the symlinks. I am not using a git (or other) plugin. I tried listing things in MANIFEST.in, for example using: graft my/package/templates/ graft my/package/templates/libraries unfortunately that had no effect: libraries was not included, not as symlink nor as a copy of the symlink target. I don't know whether MANIFEST.in is supposed to support symlinks or not, but the fact that it's working with subversion is strongly indicative that setuptools' file finder is picking up stuff that MANIFEST.in is not. I don't know *why* MANIFEST.in wouldn't pick up symlinks, though. Perhaps you could try boiling this down to a simpler test case (e.g., subversion and git versions of the same minimal package containing only a symlink referred to by MANIFEST.in) so we can narrow it down some more? Wichert. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] How to best install pkg_resources?
At 06:30 PM 12/14/2010 +0100, Arve Knudsen wrote: Argh :( Can you describe some other way of customizing the install command that works better with setuptools? That depends on what you're trying to do; but probably it will involve subclassing the install command rather than simply invoking it. What are you trying to customize, anyway? There really aren't many user-serviceable parts inside; you'd probably be better off customizing subcommands (like install_lib or some of the build_* commands). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] How to best install pkg_resources?
At 07:30 PM 12/14/2010 +0100, Arve Knudsen wrote: On Tue, Dec 14, 2010 at 7:22 PM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 06:30 PM 12/14/2010 +0100, Arve Knudsen wrote: Argh :( Can you describe some other way of customizing the install command that works better with setuptools? That depends on what you're trying to do; but probably it will involve subclassing the install command rather than simply invoking it. What are you trying to customize, anyway? There really aren't many user-serviceable parts inside; you'd probably be better off customizing subcommands (like install_lib or some of the build_* commands). I don't have the project in front of me right now, but what I needed to do was to install something non-Python. That is, if the package gets installed under prefix/lib, the extra data gets installed under prefix/data. The data is part of the project, but not part of the Python package(s). That's not going to work except in the old-style installation mode. With a setuptools or distribute project, your only places to store data are inside the package or in the metadata (e.g. a subdirectory inside .egg-info). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] namespace packages ok to contain code?
At 05:11 PM 12/13/2010 -0600, Brad Allen wrote: Where I work we're considering a change to moving a group of packages to using namespaces. We want the namespace paths to reflect a dependency hierarchy, Note that you don't *need* to use namespace paths to reflect dependencies; the main purpose of namespace packages is to allow you to separately distribute parts of a larger package, and to avoid naming conflicts with code produced by other organizations. (In other words, it's a rare use case that really needs even *two* levels of namespace package; the common use is simply to make one parent namespace package for your organization. In general, the flat is better than nested rule of Python still applies. ;-) ) Some have warned this is not usually done, but no specific problems with this approach have been identified. Any guidance on this would be appreciated. As Martin said, don't put code in the __init__.py of a namespace package. (And parent packages of namespace packages count as namespace packages.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] custom site_dirs location
At 01:54 AM 12/14/2010 +0100, adso wrote: Hi, i am doing something wrong probably, but when i try to get a custom site-packages location in Debian, i need to set the contents of altinstall.pth just several line with the absolute paths. If i use the usual python code with site.addsitedir() in Are you using import site; site.addsitedir(...), or just site.addsitedir(...)? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Unable to install packages after specifying package version
At 04:04 PM 12/7/2010 +0530, devyan parmar wrote: On Fri, Dec 3, 2010 at 10:14 PM, P.J. Eby mailto:p...@telecommunity.comp...@telecommunity.com wrote: At 04:25 PM 12/3/2010 +0530, devyan parmar wrote: Hello, i am trying to install package from my packageserver using PIP. for example: m trying /bin/pip install --extra-index-url=http://mypkgserver/devhttp://mypkgserver/devhttp://mypkgserver/dev package_name==2.4.12b 2.4.12b is the version of my package but in package server it is going as 2.4.12b_1 extra part in version is nothing but a build number which getting generated from hudson JOB. is setuptool avoids extra build number which goes with my pcakage version ?? No. That's why it's not being found. Ask for package_name==2.4.12b-1 instead. Is there any way to avoid the extra hudson build number which is coming with my package version ?? Er, don't put it in there? coz i need that build number to check which package build test got failed...and issue is in package/setup.py i am specifying only versions of dependent package. Don't use '==', then, use '='. and pip install is looking for only those particular version package in package server, but finds hudson build number attached with package version which is mismatching with setup.py install requires . can you help me how version is getting identified from the package by setuptools.?? Thanks Regards devyan parmar ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] specifying dependencies to latest major/minor
At 03:14 PM 12/3/2010 +0100, Alan Franzoni wrote: Hello, I've got some issues with dependency specification; this seems to apply both to setuptools and distribute. Let's suppose I want to have a dependency on a certain library major.minor , because I want to depend on a certain API - which is supposed to be stable for that lib unless at least the minor changes - but I want to pick in any bugfix release they might end up with. I'd like to do something like pick up the latest 1.1 release of mylib The only way to do it seems to be this: install_requires = [ mylib=1.1, 1.1.999 ] if I use just == 1.1 , it picks 1.1.0 . If I use = 1.1 and 1.2.0, it will pick beta releases for 1.2 as well. Use =1.1,1.2dev. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Unable to install packages after specifying package version
At 04:25 PM 12/3/2010 +0530, devyan parmar wrote: Hello, i am trying to install package from my packageserver using PIP. for example: m trying /bin/pip install --extra-index-url=http://mypkgserver/devhttp://mypkgserver/dev package_name==2.4.12b 2.4.12b is the version of my package but in package server it is going as 2.4.12b_1 extra part in version is nothing but a build number which getting generated from hudson JOB. is setuptool avoids extra build number which goes with my pcakage version ?? No. That's why it's not being found. Ask for package_name==2.4.12b-1 instead. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install from source?
At 03:05 PM 12/3/2010 -0600, s...@pobox.com wrote: I installed the 0.39 version of python-sybase using easy_install -m. That worked fine, but that version is extremely old. Is there a way to use easy_install with the a checkout from the project's version control system? I see this in the help output: --local-snapshots-ok (-l) allow building eggs from local checkouts but how do I specify the location of the local checkout? Just easy_install /path/to/checkout, assuming there's a /path/to/checkout/setup.py. (The -l option only enables the use of packages that were locally installed using 'setup.py develop'.) Thanks, -- Skip Montanaro - s...@pobox.com - http://www.smontanaro.net/ ___ 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] installing to a non-standard directory
At 03:39 PM 11/20/2010 -0800, K. Richard Pixley wrote: Context #1: an alternate packaging mechanism. I want to use that packaging mechanism because it's the most appropriate way to package and distribute my module for this application. The packaging mechanism involves calling install, (typically make install prefix=/tmp/jail, but there's no reason it couldn't be python setup.py install), in a sort of jail. Anything installed during that encapsulation is recorded and those pieces are the ones which are picked up and packaged by the automatic packaging system. Use --root, then. That's what it's for. Context #2: cross development. I'm running on one system producing a root file system which will be used later to boot a new system. This is another application of make install PREFIX=/tmp/newroot Likewise, this is what --root is for. In both of the above cases, you want the prefix of anything you build to be set up for the prefix where it's really going to *end up* installed, not to the temporary directory where you're mock-installing it to. That's why all distutils' internal commands use --root when they call an install operation for packaging. What I want to do is to manage and build my tool in python, including nose tests outside of bitbake, as a component within openembedded. This means that bitbake will build the component and install the component into a staging area which is unique to this particular build directory. It can then import the tool from the local staging area and use it. What I want to do is the moral equivalent of make install prefix=foo or make install DESTDIR=foo. It's a common task with numerous applications. This shouldn't be difficult and I really can't believe that I'm the first person using python to want to do this. It's a 10 character command line option. There should be something comparably simple in distutils/setuptools/whatever, no? Yes. It's --root. ;-) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] installing to a non-standard directory
At 03:18 PM 11/19/2010 -0800, K. Richard Pixley wrote: I'm trying to install to a non-standard directory. Why? It makes a difference as to what the best way to do it is. For example, if you're planning to install a Python application or create a restricted development environment, you might be better off using a virtualenv. Or, alternatively, you may want to configure your ~/.pydistutils.cfg to set the default installation paths rather than having to specify them on the command line for every package you install. distutils.errors.DistutilsError: can't create or remove files in install directory The following error occurred while trying to add or remove files in the installation directory: [Errno 2] No such file or directory: '/home/rich/projects/rcmp/junk/lib/python2.6/site-packages/test-easy-install-12743.pth' The installation directory you specified (via --install-dir, --prefix, or the distutils default setting) was: /home/rich/projects/rcmp/junk/lib/python2.6/site-packages/ This directory does not currently exist. Please create it and try again, or choose a different installation directory (using the -d or --install-dir option). As the above says, the path you're trying to install to doesn't exist. (The next thing you'll find after you fix that, is that it isn't on your PYTHONPATH.) What are you trying to install, and why do you want to install it in that specific directory? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setuptools vs distribute on Debian
At 04:51 PM 11/18/2010 +0100, Manlio Perillo wrote: Now, I read that this is a Debian policy: for some reasons they force me to use distribute instead setuptools. Have you tried installing setuptools from source? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pkg_resources: Loading resources in a uniform fashion
At 12:10 PM 10/29/2010 +0200, Alan Franzoni wrote: On Fri, Oct 29, 2010 at 5:24 AM, P.J. Eby p...@telecommunity.com wrote: PEAK does, but it's even less frequently updated than setuptools. Â ;-) Â There may be other things out there as well, I don't know. I peeked through PEAK, but it's quite a large collection of tools. Would you point me to a more precise subpackage, please? peak.naming provides lookup services for URLs and other sorts of names; peak.binding provides ways to link object attributes to automatically look up relevant objects. There is very little documentation, as the PEAK core packages were a toolkit I and a friend developed for use in our enterprise jobs. In any case, this is now off-topic for distutils-sig; if you are still interested, you should follow up via the PEAK mailing list here: http://www.eby-sarna.com/mailman/listinfo/peak -- Alan Franzoni -- contact me at pub...@[mysurname].eu ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install not choosing source package on pypi
At 02:38 PM 10/28/2010 -0700, Tom Miller wrote: Hello, I'm trying to install GoogleCL using easy_install on a Mac. Here's what I see: $ easy_install googlecl Searching for googlecl Reading http://pypi.python.org/simple/googlecl/http://pypi.python.org/simple/googlecl/ Reading http://code.google.com/p/googleclhttp://code.google.com/p/googlecl Best match: googlecl 0.9.11-win32 Downloading http://googlecl.googlecode.com/files/googlecl-0.9.11-win32.ziphttp://googlecl.googlecode.com/files/googlecl-0.9.11-win32.zip Processing googlecl-0.9.11-win32.zip error: Couldn't find a setup script in /var/folders/++/++3tbk++6+0++4RjPqRgNE+-SNw/-Tmp-/easy_install-3Y5tAg/googlecl-0.9.11-win32.zip There's a source package on pypi that apparently gets skipped over: http://pypi.python.org/pypi/googlecl/0.9.11http://pypi.python.org/pypi/googlecl/0.9.11 plus the Download URL field is filled in with a link directly to the correct file. Instead, easy_install grabs the first download listed in the project home's download links, which happens to be a .zip with an executable for Windows users. What's going on here? By the naming conventions setuptools uses, a file named googlecl-0.9.11-win32.zip is a source package for version 0.9.11-win32 of googlecl, and thus is used in preference to the lower-versioned http://googlecl.googlecode.com/files/googlecl-0.9.11.tar.gzgooglecl-0.9.11.tar.gz. If you named that file, say, googlecl-win32-0.9.11.zip instead, then this confusion would not occur. Is there a way to indicate the correct file, or does the package description need to be updated? Thanks, - Tom ___ 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] easy_install not choosing source package on pypi
At 11:58 AM 10/29/2010 -0700, Tom Miller wrote: Great, thanks. I guess there's no way to tell easy_install to look for a specific extension? Or to use the file hosted at pypi? If you're the person doing the installing, then of course you can manually specify a URL, or use easy_install googlecl==0.9.11 to force the right file to be selected. However, if you're the package author and want to fix it for everybody, you can either rename the non-applicable file, or remove the Home Page link from the PyPI pages that it's on. (You'd have to remove it from every version you've ever published on PyPI, though, even if it's an inactive one.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pkg_resources: Loading resources in a uniform fashion
At 06:18 PM 10/28/2010 +0200, Alan Franzoni wrote: Hello, lately I was thinking about writing a kind of factory method for parsing an url and returning a resource filename or stream, something like: fs_resource = load_resource_filename(file:///etc/software/config.conf) pkg_resource = load_resource_filename(pkg://package.something) I'd like the first one to just return the file system path /etc/software/config.conf, while I'd like the second one one to do something roughly like from pkg_resources import resource_filename return resource_filename(package, something) This way it would be pretty easy to get a consistent way to describe a resource from a stream. I've got some questions: 1) is there anything around that already does something like that? PEAK does, but it's even less frequently updated than setuptools. ;-) There may be other things out there as well, I don't know. 2) would you think it to be a good addition for pkg_resources, or would it go beyond its scope? Way beyond scope. It makes more sense for it to be part of a url management package. 3) can you see some obvious issues? 4) how would you handle requirements string? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] sh execution of setuptools egg not working
At 06:10 PM 10/28/2010 -0400, Stephen Waterbury wrote: Any suggestions appreciated! Hope this isn't a faq that I missed ... I would suggest trying it with the local Python 2.4; if that works, then your 2.6 build is likely broken in some way. (Another thing to check would be your PYTHONPATH.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Unable to write into TMP directory during installation
At 09:29 AM 10/26/2010 +0300, anatoly techtonik wrote:
Hello,
How come that packages are unable to write into TEMP directory during
installation?
Because projects that write anything outside of distutils-defined
directories are breaking the implicit contract of a distutils-based
installation, and that means that easy_install cannot guarantee that
the installation will proceed correctly. That is why the message
says the package cannot be safely installed by EasyInstall.
(I suppose it could say instead that EasyInstall cannot be sure
whether installation is safe, and is thus refusing the temptation to
guess, but that would make the message a bit longer.)
In this specific case (Gerald), the package has two problems that
are causing this error: first, it is trying to import the package
before it is installed, and second, it writes files as a side-effect
of this importing. (The author seems to have tried to work around
the usual consequences of the first problem, but that can't mitigate
the second problem.)
While neither of these things is technically illegal, they are in the
first case bad practice for installation, and in the second case, bad
programming practice for a library. (Gerald appears to be an
application rather than a library, of course, but even so, an
application shouldn't be started up before it's been installed --
especially not if it's writing files outside the build/install directory.)
All this being said -- a future version of easy_install could (and
perhaps should) reset TEMP/TMP in the installation sandbox to
something that's actually usable.
python -m easy_install gerald
...
Downloading
http://pypi.python.org/packages/source/g/gerald/gerald-0.4.1.zip#md5=1b29e97c0077282a26829693fb07dca1
Processing gerald-0.4.1.zip
Running gerald-0.4.1\setup.py -q bdist_egg --dist-dir
c:\users\user\appdata\local\temp\easy_install-1jedvu\gerald-0.4.1\egg-dist-tmp-wg8yyn
error: SandboxViolation:
open('C:\\Users\\user\\AppData\\Local\\Temp\\gerald.log', 'a') {}
The package setup script has attempted to modify files on your system
that are not within the EasyInstall build area, and has been aborted.
This package cannot be safely installed by EasyInstall, and may not
support alternate installation locations even if you run its setup
script by hand. Please inform the package's author and the EasyInstall
maintainers to find out if a fix or workaround is available.
--
anatoly t.
___
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] easy_install MySQL-python file error
At 03:41 PM 10/18/2010 +0200, Jonathan Endy wrote:
Hi,
When I am trying to install MySQL-python package
I receive an error, this is the output:
F:\PythonF:\Python\Python25\Scripts\easy_install.exe
F:\Python\MySQL-python-1.2.3
Processing MySQL-python-1.2.3
Running setup.py -q bdist_egg --dist-dir
F:\Python\MySQL-python-1.2.3\egg-dist-tmp-ly3u1l
error: The system cannot find the file specified
Does anyone have an idea what casing that or how to spot the problem?
Try this:
cd F:\Python\MySQL-python-1.2.3
F:\Python\Python25\python.exe -c import setuptools;
execfile('setup.py') bdist_egg
And send the full output.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install MySQL-python file error
At 07:07 PM 10/18/2010 +0200, Jonathan Endy wrote: Have you encountered this situation? No, but at least now you know the problem is with your build environment. I personally use cygwin with the MinGW package, installed using cygwin's installer. I then run builds and installation from the cygwin command line, but using a Windows Python. I'm afraid I can't help much more than that. There is supposed to be a free version of the Microsoft compiler you can use to do this instead, but I've never tried that. You may wish to simply use 1.2.2 instead, via: easy_install -f http://sourceforge.net/projects/mysql-python/files/ MySQL-python==1.2.2) as that version has pre-built Windows binaries for Python 2.5. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Recent buildout failure in Mailman 3
At 11:46 AM 10/11/2010 -0400, Barry Warsaw wrote: On Oct 08, 2010, at 11:37 PM, P.J. Eby wrote: At this point, I'm a bit stumped, as I don't know enough about how tarballs are supposed to work internally; should I just whip up a patch for the situation where the path has no slashes in it (the logilab case), or do I need to do something more sophisticated in the general case? I don't know, but the fix you did commit fixes the build problem for me. But it still doesn't fully extract the archive. The problem should now be fixed entirely in the latest snapshot -- in addition to not matching the path processing correctly, I had an extraneous argument being passed to getmember(). ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install best match issue
At 12:07 AM 10/11/2010 +0200, Alan Franzoni wrote: Hello, I've just run into a strange issue I'm not able to solve without further info. Maybe it's a problem with Macports or with my config. I'm trying to install the byteplay pypi module on macosx 10.6.4, python 2.6.6 built by Macports, distribute 0.6.14 installed. So here I go: melquiades:/ alan$ sudo /opt/local/bin/easy_install-2.6 byteplay install_dir /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/ Searching for byteplay Reading http://pypi.python.org/simple/byteplay/ Reading http://code.google.com/p/byteplay Reading http://code.google.com/p/byteplay/downloads/list Best match: byteplay 0.2.linux-i686 Downloading http://pypi.python.org/packages/any/b/byteplay/byteplay-0.2.linux-i686.tar.gz#md5=8243c7004826cccd182fd0c58f75fb0e Processing byteplay-0.2.linux-i686.tar.gz error: Couldn't find a setup script in /tmp/easy_install-oYBFVP/byteplay-0.2.linux-i686.tar.gz melquiades:/ alan$ There're two separate issues I see here: - why does easy_install pick the dumb binary dist as the best match even though prebuilt eggs are available? - why does macosx easy_install pick a LINUX dumb binary dist as the best match? Because it thinks that 0.2.linux-i686 is a version number, and thus a higher version than '0.2'. easy_install byteplay==0.2 should fix you up. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Recent buildout failure in Mailman 3
At 03:48 PM 10/8/2010 -0400, Barry Warsaw wrote: I just got a new report of a buildout problem with Mailman 3.0a6. https://bugs.edge.launchpad.net/mailman/+bug/656946 The first part of the problem (corrupt eggs) was easily fixed. It was caused by a faulty MANIFEST.in that let eggs/ and parts/ leak into the tarball. However, even with that fixed, buildout is failing for reasons I can't yet figure out. A full build is pastebin'd here: http://pastebin.ubuntu.com/509012/ I've tried pinning the setuptools version number 0.6c12 and I've tried pinning the logilab-common package to 0.52, but neither workaround helps. I actually can't tell where the problem is: is it setuptools, distribute, logilab-common or something else? It *feels* like a bug in setuptools-0.6c12dev. I recently added symlink extraction support to 0.6c12dev; apparently it doesn't work with the symlink found in logilab-common. (I'll have to investigate further to find out why.) Older versions of setuptools simply didn't extract symlinks at all, so this problem didn't occur there. I've put in a workaround ( http://peak.telecommunity.com/snapshots/setuptools-0.6c12dev-r85332.tar.gz ) to fix the immediate issue (which is that an unextractable symlink causes an error), and next week I'll take a look at finding out why this *particular* symlink isn't extractable. (Preliminary guess: the tarfile module doesn't support relative links, and thus needs some path fixup help from setuptools.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Copying entire directory
At 07:06 PM 10/6/2010 +0200, Friedrich Romstedt wrote:
2010/10/6 Fred Drake fdr...@acm.org:
On Wed, Oct 6, 2010 at 12:54 PM, Friedrich Romstedt
friedrichromst...@gmail.com wrote:
It's in my
opinion always a good idea to try to avoid hard-coding directory
separators (/), and to use os.path.join() instead.
Distutils specifically wants / rather than the local platform's
separator, and takes care of conversion as needed.
Sure, thanks for the correction! Don't know if glob would need
platform-specific separators, though?
glob accepts '/' on most platforms, but returns platform-specific
separators. For this application, though, it's simpler to just use
['prefix/'+f for f in os.listdir('prefix')].
Or, if you like obfuscational, er, I mean, functional programming,
you can user:
map('prefix/'.__add__, os.listdir('prefix'))
;-)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Copying entire directory
At 04:21 PM 10/5/2010 +0200, Roberto Riggio wrote:
Hi,
I'm not sure if I'm doing something wrong, anyway, I want to
copy the content of a directory included in a package generated with
./setup sdist to a certain destination.
What I did is to add something like this to my setup.py:
data_files = [('etc/foo/www/', [ 'dashboard/*' ])]
Just to put things into a context: the directory dashboard contains a
number of html files that are served by my application. I cannot list
all the files one by one because are too many, but also the apprach
that I'm using does not work and produce the following error:
error: can't copy dashboard/*: doesn't not exist or not a regular file
Any suggestions?
data_files = [('etc/foo/www/', ['dashboard/'+f for f in
os.listdir('dashboard')])]
(I would also question the idea of targeting installation directories
in this way for a general-use package, but that's a separate issue.)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Copying entire directory
At 07:31 PM 10/5/2010 +0200, Roberto Riggio wrote:
On 10/05/2010 06:39 PM, P.J. Eby wrote:
data_files = [('etc/foo/www/', ['dashboard/'+f for f in
os.listdir('dashboard')])]
(I would also question the idea of targeting installation
directories in this way for a general-use package, but that's a
separate issue.)
Why? Which would be a better approach? My software is a daemon
that implements a p2p overlay. The files are an ajax interface to the
daemon that is served by an embedded web server.
That's not a general-use package. ;-)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Oddities in setuptools/distribute
At 04:31 PM 10/5/2010 -0400, Barry Warsaw wrote: I'm working on some patches that allow for multiple builds of Python with different options to coexist. This is an extension to PEP 3149 and has been discussed recently in python-dev: http://mail.python.org/pipermail/python-dev/2010-October/104382.html This has led me into the twisty maze of setuptools and distribute: http://mail.python.org/pipermail/python-dev/2010-October/104430.html I believe I've figured out a patch that *should* make this work, but doesn't, and I have a few questions about some things I've noticed: 1) Why does setuptools write a stub loader for the .so in the first place? Why not just let the import of the shared library happen directly using the normal Python import rules? It does. The normal import rules load .so files first, so the stub loaders only have an effect if the module is imported from a *zipfile* (where .so files won't normally load at all). When unzipped, the .py file is ignored, and so has no effect. But when zipped, it forces extraction of the .so to a cache directory, where it can then be imported. 2) Why does build_ext.py and bdist_egg.py have similar but slightly different stub writers? I'm sure there's an important reason for this, but at least in the case of shared library loading, it seems like the two stubs ought to be more similar than they are. Dynamic shared library support in setuptools is still officially an experimental feature, so there's some possibility that this is a bug. That is, bdist_egg's stubs may be broken for extensions using dynamic library loader stubs. 3) Why does site-packages/package.egg/ get deleted when the package is re-installed? Because if you're reinstalling it, it's presumably because the original is fux0red in some manner. Also, depending on your command-line options, you might be installing an .egg file where a directory existed before, or vice versa. Can this be prevented? This is actually the show-stopper I'm stuck on because if I install my extension with build-A of Python, then try to install it with build-B of Python, the build-A version gets wiped. Because the shared libraries now have build-flag discriminators in the file name, the two installs *should* be able to coexist, On a version of Python that does this, it would probably be best if the platform string included the build flags -- then you would have two separate .eggs, each of which would only be loaded by a compatible runtime. Thanks for any feedback you can provide. Thanks for asking! ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Oddities in setuptools/distribute
At 09:32 PM 10/5/2010 -0400, Barry Warsaw wrote: It probably would be better to only blow away the original egg when a --reinstall option were given. This might change current semantics too much, so a --keep option would probably be in order. My worry here is that this breaks the invariant that .egg files and .egg directories are identical/interchangeable. I'm not sure whether there's anything in the ecosystem that depends on that (besides perhaps the --always-copy flag to easy_install, which I'd have to check to see if it depends on that). For zip'd eggs, you might be right. For egg directories, it's not necessary. Everything is sharable, and when not (i.e. the .so's) they are build-flag discriminated. I'd like to share as much as possible, but I'm open to any suggestions. Given that platform string discrimination has been battle-hardened by many years of deployment, my personal inclination is to suggest that approach. The relevant functions are: * pkg_resources.get_build_platform() -- returns the minimum platform string that should be used for eggs built by this interpreter * pkg_resources.get_supported_platform() -- returns the platform string that represents the maximum platform supported by this interpreter * pkg_resources.compatible_platforms(provided, required) -- Can code for the `provided` platform run on the `required` platform? In practical terms, though, you could probably just change distutils.util.get_platform() (or whatever it's called in Py3) to add the debug and width flags to the platform string. The get_*_platform() functions are based on that, and the default compatibility check is just string equality. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] implementing egg-info/pkg_resources source support for custom importers
At 11:09 PM 10/1/2010 +0200, Ronny Pfannschmidt wrote: hi, I'm implementing a custom pep302 importer in order to ship sets of python packages within a generated python script, I'd like to support egg-info entry-points, so I can ship extensions as well as choose the script entry-point based on the executable name. However I couldn't find simple docs on doing that. You need to register some adapters for your importer type, using the functions described here: http://peak.telecommunity.com/DevCenter/PkgResources#supporting-custom-importers Essentially, you will need to define two functions and a class: def my_finder(path_item, importer, only): # yield Distribution objects for path def my_namespace_fixer(importer, path_item, modulename, module): # return a __path__ entry to add to module class MyProvider(EggProvider): def _has(self, path): # os.path.exists(path) def _isdir(self,path): # os.path.isdir(path) def _listdir(self,path): # os.listdir(path) def _get(self, path): # open(path,'rb').read() and then register them like so: register_finder(MyImporter, my_finder) register_namespace_handler(MyImporter, my_namespace_fixer) register_loader_type(MyLoaderType, MyProvider) Without knowing how your PEP 302 importer works, it's hard to get more specific than this; it all depends on how your sys.path entry strings are formatted. Are you using a virtual OS path the way .zip paths work, or something else? (If you're using pseudo-OS paths, you can reuse pkg_resources.file_ns_handler in place of writing your own my_namespace_fixer.) Note, by the way, that if your system doesn't physically place individual files on disk, you probably actually want something that emulates .egg rather than .egg-info, as then you can support resource_filename() operations. (In which case, you'll probably also subclass ZipProvider rather than EggProvider.) So, yeah, there are no simple docs. ;-) It would probably be good if pkg_resources had better support for rolling your own stuff over a virtual file system; it already has some, but the finder part could be a lot simpler if there was a way to reuse the built-in ones with a VFS, and the provider class would be easier if the parts of ZipProvider that aren't truly zipfile-specific were moved to EggProvider or NullProvider. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install with post-install script
At 05:05 PM 9/27/2010 +0200, Lacko Roman wrote: Thanks for reply, Add a script to your package that performs the installation step (or an option to an existing script), and then ask the user to run it after the install is complete. Yes this is how I resolved the problem before (No, there's no automated way.) Do You plan to support this in future ? I don't have a specific plan, but am open to finding ways to do it. Those ways, however, need to allow users to know what the post-install operations are doing/going to do (with explicit user consent), along with having uninstall capabilities. Thanks -Roman -Original Message- From: P.J. Eby [mailto:p...@telecommunity.com] Sent: Monday, September 27, 2010 4:33 PM To: Lacko Roman; distutils-sig@python.org Subject: Re: [Distutils] easy_install with post-install script At 10:41 AM 9/27/2010 +0200, Lacko Roman wrote: Hi, Is there some way to run some post-install script when installing the python package with easy_install ? I need to create some files in folder where the python interpreter is located. BTW It is possible with bdist_wininst, because it support post installation scripts, but not with easy_install. Add a script to your package that performs the installation step (or an option to an existing script), and then ask the user to run it after the install is complete. (No, there's no automated way.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Distribute error? datetimewidget.pot: File name too long
At 02:45 PM 9/24/2010 +0100, Jon Hadley wrote: I'm trying to install a custom package in a buildout managed Plone 3 site in /develop-src named (for the sake of argument) 'foobar.wontbloodywork'. Yet I keep getting an error 'z3cform.datetimewidget.pot: File name too long' I get the same result on a freshly built Ubuntu server with no previous eggs. The custom packages used to install fine in an older (12 month +) project. It was suggested to me (via the Plone Users mailing list) that this might be a distribute error. Can anyone on this list offer any insights? Have you tried it using plain setuptools (0.6c11 or greater)? There are some bugs in distribute regarding recursive build-time dependencies that were fixed in setuptools last October, but which are still outstanding in distribute. From your logs, it rather looks as though you've got a situation where collective.z3cform.datetimewidget has a build-time dependency on itself, so I'd like to know if setuptools can handle it correctly as well. easy_installing the package directly works fine on my machine with setuptools; does distribute work for this as well? If doing an easy_install or plain setup.py install works correctly with distribute, then the problem is probably in buildout rather than setuptools or distribute. (I checked and the datetimewidget project (v1.0.2) does not declare any build-time dependencies, so there shouldn't be any recursion possible... yet it appears to be taking place in your log nonetheless.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] easy_install command arguments not propagated when installing source distributions
At 12:23 PM 9/23/2010 -0700, Jason R. Coombs wrote: I understand the challenge here - setuptools is launching setup.py from the source distribution for jaraco.compat, and setup.py doesn't accept parameters for 'allow_hosts' and 'find_links'. Hm. This is actually a bit of a hole with respect to --allow-hosts. I'll have to see if there's a way to pass that information through (probably not as a setup.cfg file, though). Is there any way that we can use source distributions in this environment (without customizing each source distribution for the environment)? If not, perhaps an improvement could be added to setuptools to populate a setup.cfg file when installing source distributions to include the easy_install flags supplied to the requiring install. In the meantime, one quick fix you could implement is to add a distutils.cfg to the Lib/distutils/ directory of your Python installation(s). If you want to do this in a (semi-)automated way, you can run this in any project source directory: python setup.py saveopts -g easy_install [options to save] This will save whatever options you give to the global config file for you. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [issue116] typo in command.bdist_enc.make_zipfile
At 03:10 AM 9/21/2010 +, Ted Tibbetts wrote:
Looks like there is a typo in the function `make_zipfile` in the
file `command/bdist_enc`: the last line of the else clause of the if
construct at the end of the function passes `file` as the third
parameter to `visit`; it should be passing `files`, I think.
Symptoms include the exception `TypeError('instancemethod' object
is not iterable)` when attempting to run `easy_install -n some_sdist.tar.gz`.
Applying the attached patch seems to resolve the issue; I'm still
not entirely sure what it's telling me, but at least it's not
spitting out a stack trace.
Hi Ted. It appears you are using distribute, not
setuptools. Unfortunately, some Linux distributions are shipping
distribute (a fork of setuptools) under the name setuptools, which
creates user confusion. If you are using your Linux distribution's
installation of setuptools, please make sure to file this bug with
your Linux distributor as well.
Distribute has many changes relative to setuptools, some of which
have introduced new bugs. It looks like this is the specific change
that introduced the problem you're experiencing:
http://bitbucket.org/tarek/distribute/changeset/512db2c962e4
In this case the problem is fairly minor, since it only affects dry
runs that would probably fail later in the process anyway.
Unless you are using Distribute by choice for its additional
features, you may wish to uninstall it and replace it with a stable
version of setuptools. (Unfortunately, if you are using your Linux
distributor's installation of it, this may not be possible.)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribution name capitalisation considered important ; -)
At 09:37 AM 9/20/2010 +0100, Chris Withers wrote: On 15/09/2010 19:58, P.J. Eby wrote: I can't speak to the others, but setuptools *always* ignores case. If you have found it not to, please file a bug report so I can fix it. Where's the right place to report? http://bugs.python.org/setuptools/ The problem I had was using a file:// to find-links on Windows, whereby setuptools ends up causing os.path.normcase to be called on the distribution name, lowercasing an otherwise perfectly correctly cased distribution name... ...resulting in what problem? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] please fix easy_install shorter URL preference (Was: easy_install wrong download site preference)
At 07:59 PM 9/18/2010 +0300, anatoly techtonik wrote: On Sun, Sep 12, 2010 at 9:08 PM, P.J. Eby p...@telecommunity.com wrote: That issue was fixed in October 2009, so you are likely using something 0.6c11. I am using setuptools-0.6c11-py2.6.egg on Windows Vista. Oops. My bad - this was actually fixed only 7 months ago, in February 2010, and it's not in 0.6c11, only the nightly snapshots. To update your installation, run: easy_install -U setuptools This should give you 0.6c12dev-r_something_or_other. ;-) Note, however, that since the full source distribution *also* includes the python code, all that's needed is to change its setup.py slightly and move it to the root of the source tree. If the Python was the only code inside - that'd be acceptable, but it seems like the proper fix lies in setuptools AI code. You do realize that asking everybody to update their version of setuptools in order to be able to install one particular package is a little unrealistic? I mean, *your* setuptools is at least seven months out of date, so even if I changed this, how long would it be till your users updated? ;-) In truth, I do have an idea that would actually fix this problem in the Google case (a change to the way the source is processed after extraction), but it will likely be a while before I can implement it, and a while further still before everyone has installed the update. (Note that 0.6c5 and 0.6c9 are still very popular versions, and 0.6c9 is like *two years* out of date.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribution name capitalisation considered important ; -)
At 04:59 PM 9/15/2010 +0100, Chris Withers wrote: On 15/09/2010 16:57, Sridhar Ratnakumar wrote: On 9/15/2010 6:53 AM, Chris Withers wrote: Looks like we have quite a consistent set of rules with regard to captilisation of package names on file systems where case isn't important, shame the same can't be said for distribution names. [...]These differences cause subtle problems in tools which attempt to pin versions of particular distributions. Going by what you wrote about pinning versions, are you talking about Buildout? Yes, but I expect the subtleties apply to otehr tools too... The only sane option now would be for all distribution names to be lowercased by all tools all of the time. How do others feel about this? pip, easy_install and pypm already ignore case. ...sometimes ;-) I can't speak to the others, but setuptools *always* ignores case. If you have found it not to, please file a bug report so I can fix it. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] whats the best way to depend on tools needed for setup.py/setup metadata
At 08:53 PM 9/14/2010 +0200, Ronny Pfannschmidt wrote: Hi, i'd like to support turning my guess version from hg metadata tool into a setup dependency and thus kill the need to ship a python file. Currently i just import it + call a function, but that doesn't exactly work if the module is missing and a dependency. Is there any way to turn it into some sort of plugin/extension that automatically gets installed/used to get that metadata. See my answer here: http://mail.python.org/pipermail/distutils-sig/2010-August/016690.html And Jason's follow-up here: http://mail.python.org/pipermail/distutils-sig/2010-August/016694.html You may also want to take a look at what hgtools is doing, to get the exact code. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [ANN] setuptools post install script for bdist_wininst
At 02:03 PM 9/13/2010 +0200, Manlio Perillo wrote: The simplest solutions are: * use py2exe or pyinstaller The problem is that there are some issues using them: - my scripts are handled by setuptools, and I use pkg_resource plugins and project data; this seems to not be supported I'm not sure what you mean. If your scripts import pkg_resources, it should be included in the resulting .exe or distribution. - python = 2.6 support have several issues Is that just a general issue with py2exe/pyinstaller, or is there something specific to setuptools? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] please fix easy_install shorter URL preference (Was: easy_install wrong download site preference)
At 12:08 PM 9/12/2010 +0300, anatoly techtonik wrote:
https://sourceforge.net/apps/trac/halfcooked/ticket/29
Gerald is the second package from the last 4 months that I couldn't
install due to this very obscure behavior, and I suspect there are
more.
Gerald installs fine when I try it, and from the same URL (which
isn't the shortest in any case). I suspect you are not using the
current version of easy_install, as the problem shown is due to
Sourceforge's use of '/download' URLs.
That issue was fixed in October 2009, so you are likely using
something 0.6c11.
(Or perhaps you are using distribute, which has still not applied
this bug fix almost a year later.)
Phillip, could you, please, still run through your archives to success
in explaining why this logic of choosing a shorter download URL is
necessary? I'd really to see what packages benefit from it,
It was originally added for PIL and other effbot-released packages;
it's retained because to change it now would introduce random
breakages to other projects, in order to benefit one whose source
filenames are ambiguous anyway.
I believe Google protocol buffers popularity alone is enough to change
the behavior.
Right now, the naming of the two source distributions is ambiguous,
even for humans.
Note, however, that since the full source distribution *also*
includes the python code, all that's needed is to change its setup.py
slightly and move it to the root of the source tree.
(The changes needed would consist of adding
'package_dir={:python}' to the setup() options, and changing
relative path uses in the setup.py so that they don't assume the
current directory is the 'python' subtree... i.e., mainly just
changing all '../src' occurrences to 'src'.)
In the alternative, calling the release that contains all languages
'protobuf-all-2.3.0.*' rather than 'protobuf' would also fix the issue.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [ANN] setuptools post install script for bdist_wininst
At 02:36 PM 9/12/2010 +0200, Manlio Perillo wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/09/2010 23:22, P.J. Eby ha scritto:
At 09:48 PM 9/11/2010 +0200, Manlio Perillo wrote:
Is it possible to put required DLLs inside an egg?
Yes, but they have to be adjacent to any Python extensions (.pyd's) that
use them.
Good to know, thanks.
But how can I create such a egg?
In the same way that you'd create a distutils-based package that
installs shared libraries next to Python extensions. (i.e., not easily.)
And if this is possible, what do you think is the reasons why packages
like pyqt do not release such eggs?
Because major C extensions (e.g. wx, numpy, pywin32) tend to have
special build requirements for their libraries that aren't handled
well by the distutils, or the build process predated the distutils,
or the build process wasn't originally designed to be used with
Python, etc. etc.
It should not be hard to track installed dependencies, as an example
using the --record option of easy_install, and then registering all
installed files (and directories) with `file_created` and
`directory_created` functions.
The only problem is that created directories are not reported in the
record, but if files are always listed ordered, it should not be a problem.
That's not the only problem: if you install A, then B, and both
depend on C, then if you uninstall A you will break B. You would
have to also track shared use of dependencies.
This situation is a big mess, and I haven't needed it for myself or
any client as yet, so I've avoided the whole subject.
Some other related questions:
* Do you think you can change ez_setup.py so that the code used to
check if setuptools must be installed is available as a separate
function?
Grab the bit that looks like this:
try:
import pkg_resources
except ImportError:
# it's not installed
else:
try:
pkg_resources.require('setuptools='+version)
except pkg_resources.VersionConflict, e:
# older version is installed
except pkg_resources.DistributionNotFound:
# it's not installed
else:
# it's installed
Season to taste. ;-)
For normal package dependencies (and assuming setuptools is
available) I can just use working_set.__contains__(dist)
No, you need to use require() or resolve() or some other API that:
1. Checks versions, and
2. Handles recursive dependencies
* Is it safe to call `ez_setup.use_setuptools` setting `to_dir`
parameter to `sysconfig.get_python_lib()`?
It's safe for setuptools, but whether it's safe in the context of a
bdist_wininst I'm not sure.
By default the setuptools egg is copied to the same directory where
the bdist_wininst file is, and this is not safe since the user may
delete these files.
You could also fix that by calling easy_install(['--always-copy',
'setuptools']), in the case where you've had to install setuptools.
* Is it possible to get the ID of the main window of the bdist_wininst
application?
I need it because MessageBox function requires the ID of the parent
window.
It is possible to use the Desktop as parent, but this may cause
problems (message box displayed in the wrong position, with incorrect
focus, or who know)
* Is it possible to modify bdist_wininst (in a future release) so that,
when executing the post install script, the name of the project being
installed is passed in argv[2]?
This change does not break existing code.
I don't know the answers to these questions.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [ANN] setuptools post install script for bdist_wininst
At 04:42 PM 9/11/2010 +0200, Manlio Perillo wrote: This is a problem with the installer, since stdout and stderr are fully buffered. You probably need to pop up some sort of dialog and direct stdout/stderr there. Alternately, you could run easy_install in a separate process as a console script. TODO In case a dependency have extension code that must compiled, in 99% of the cases the post install script will fail, since the compiler or some library is not available. This should not happen; the post install script should, instead, check if in the package download_url there is a bdist_wininst executable, download it and execute it. easy_install already does this, sort of: it downloads bdist_wininst executables and converts them into eggs, then installs the eggs. Suggestions are welcome. In general, I'm not sure that this sort of thing is wise to do in a bdist_wininst postinstall without some kind of user prompting, since: 1. A primary reason people have for using bdist_wininst installers is uninstall support, and this approach will leave dependencies behind. 2. Another big reason people have for using these installers instead of easy_install is that they don't want things being downloaded from the net, because e.g. they have no access or are behind a proxy, so this is just going to annoy them. I would strongly recommend having some sort of dialog that simply tells the user what dependencies are missing, and then asks if they would like to have them installed automatically. (So the user can then say no if they need uninstallability or have limited network access.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [ANN] setuptools post install script for bdist_wininst
At 09:48 PM 9/11/2010 +0200, Manlio Perillo wrote: Is it possible to put required DLLs inside an egg? Yes, but they have to be adjacent to any Python extensions (.pyd's) that use them. 1. A primary reason people have for using bdist_wininst installers is uninstall support, and this approach will leave dependencies behind. As far as I know, all dependencies are correctly handled. Shortcuts are correctly removed by the uninstall. But the dependencies installed by easy_install will not get corresponding uninstall entries in the Windows control panel, and so will not be uninstalled when the user uninstalls the main application or library. By the way, I tried to install pywin32, but I got: AFAIK, pywin32 is not easy_install-able due to some post-install incompatibilities. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] bdist_wininst and dependencies with setuptools
At 07:37 PM 9/9/2010 +0200, Manlio Perillo wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Today I was building a package that must be installed on a Windows system (I'm on Linux). I simply did: python setup.py bdist_inst and I was expecting that, when executed on the Windows machine, it would not only install my package, but also all dependencies declared in the setup file. This was not the case. I would like to avoid having to create an all in one installer using pyinstalled; is this possible? No; bdist_wininst doesn't support dependencies. If you need Windows users to install dependencies, they'll have to use easy_install. (I'd say or pip, but pip doesn't support installing pre-built binaries.) Note that dependencies are all pure Python modules available on pypi, except PyQt (that is installed using the installer provided by riverbank). If everything but PyQt is pure python, then you can just have them install from source using pip or easy_install. (Or, alternatively, build an executable with py2exe.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
