Hello setuptools developers,
I'm attempting to package the newest setuptools version (1.1.6)
on Solaris 9 and 10. One of the limitations of the Solaris package manager
(the old one, pkgadd/pkgrm), is that it is unable to handle file names with
spaces. Would you mind renaming "script template.py" to something like
virtualenv 1.11.1rc1 has been released, which solves a serious issue with the ``—system-site-packages`` flag.
In order to test this copy of virtualenv:
$ curl -L -O https://github.com/pypa/virtualenv/archive/1.11.1rc1.tar.gz
$ echo "e517f28a31792f00699b369932a9b66a 1.11.1rc1.tar.gz" | md5sum -c
$ tar zxf 1.11.1rc1.tar.gz
$ python virtualenv-1.11.1rc1/virtualenv.py myVE
$ myVE/bin/pip install SomePackage
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Here is what I did and the response:
Exception calling "DownloadFile" with "2" argument(s): "An exception
during a WebClient request."
At line:1 char:1
+ CategoryInfo : NotSpecified: (:) ,
+ FullyQualifiedErrorId : WebException
Traceback (most recent call last):
File "C:\Python27\Scripts\ez_setup.py", line 361, in <module>
File "C:\Python27\Scripts\ez_setup.py", line 357, in main
File "C:\Python27\Scripts\ez_setup.py", line 282, in
File "C:\Python27\Scripts\ez_setup.py", line 169, in
File "C:\Python27\Scripts\ez_setup.py", line 152, in _clean_check
File "C:\Python27\lib\subprocess.py", line 511, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['powershell', '-Command',
non-zero exit status 1
The parts in red were in red in my terminal window. I am on windows 8.1 and
I am brand new. Less than a week ago, I installed Distribute because
someone on Django Google Groups recommended it to me, along with virtualenv
and pip. Then today - well, last night since it was a few hours ago - I
found out Distribute is deprecated. So I am trying to follow the uninstall
instructions but this is what I got. Just for kicks I ran it again just now
- same result. Please help. I took time off from work Thursday and Friday
to get all this set up have been at this all weekend only to be stumped
again. And no, I do not have Django up and running yet. Thank you.
Hi Distutils folks,
I'm kind of a lurker here, due primarily to the fact that I'm too swamped with various other things to materially contribute to the effort, but I've been lurking for some time hoping to learn enough to avoid troubling anyone with pesky questions. In that respect I've apparently failed, because here comes the question!
I'm helping out with a python package: vpython <http://vpython.org> and I'm also teaching an intro scientific computing class this spring. I'm mostly a Mac/Linux user, but my students are often windows users. I would love to permit my students to use enthought/canopy and/or continuum analytics (C.A.) along with vpython. At the moment we're creating binary releases of vpython for windows and mac and posting them on sourceforge <https://sourceforge.net/projects/vpythonwx/>. Bruce has been building the windows binary using VC (no setup.py) in a way that's compatible with python.org python for windows. I've been building the mac version using a setup.py script I cobbled together that works on MacOSX and Linux. I've noticed that the anaconda system that C.A. installs uses MinGW on windows to build extensions. I'd love to figure out how to build vpython under this system so that my windows users could use them together transparently. (BTW is this the same 'anaconda' that has been discussed on this list recently, or is that something different?) I'm pretty sure I could work out how to build vpython with continuum analytics on the mac (which means building boost + wxPython using the C.A. python).
Is there any way, *today*, to incorporate dependencies on external libraries (e.g., boost) in setup.py?
(I've noticed the recent conversion about binary dependencies, but from the discussion it seemed to be mostly about the future...)
Where should I go to get the 'latest' advise/documentation on distribution for a package that I want to distribute today (rather than pestering you folks)?
University of Indianapolis
Dept. of Physics and Earth Space Sciences
spicklemire(a)uindy.edu (317) 788-3313
does buildout ever take its default index URL from the distutils
configuration, i.e. [py]distutils.cfg?
Given that it uses easy_install for most installation tasks, that could
make sense, and I'm not sure whether it is actually supposed to happen
already, but does not happen on my systems for some reason.
Thanks for any info you can give me.
So can they be sorted in the same way as the normal index? To my eye
the unsorted list looks horrible. OTOH it's too much hassle or this is
covered by the Warehouse project I won't lose any sleep over it.
Also for pypi issues
https://mail.python.org/mailman/listinfo/pydotorg-www points you to
https://mail.python.org/mailman/listinfo/catalog-sig where it states
it's retired and points you here. How do we get this changed?
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
I started putting together a list of standard library modules that are
also available on PyPI for the
https://wiki.python.org/moin/Python2orPython3 wiki page.
Dariusz Suchojad suggested it might be easier if there was a suitable
classifier to mark such modules rather than trying to keep a list on
the wiki up to date by hand. Perhaps something like "Progamming
Language :: Python :: Standard Library"?
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I've just published the first draft of the metadata 2.0 spec that
moves all of the fields that aren't part of the core metadata or
potentially needed for dependency resolution out to a separate
"standard metadata extensions" PEP.
I think this makes PEP 426 itself substantially less overwhelming, and
also provides convenient names to refer to the various other subsets
of the metadata. The new PEP defining the standard extensions is PEP
Metadata 2.0: http://www.python.org/dev/peps/pep-0426/
Standard Extensions: http://www.python.org/dev/peps/pep-0459/
You can see the full deltas for PEP 426 and PEP 440 here:
Or slightly more incremental deltas in the BitBucket repo:
With this update, I believe PEP 440 is extremely close to acceptance,
as I have tried to resolve a number of problems Donald noted while
working on Warehouse, as well as the perennial problem of how to deal
with versioning of packages where Linux distro vendors (or other
system integrators) have applied additional patches.
The PEP 440 changes:
- added the "integrator suffix" (essentially an extra release segment,
separated from the upstream version number by "-"). It is effectively
ignored by most of the matching operators, but sorts as a higher
version than the version with no suffix.
- allowed date based versions for most purposes, but still reject them
for the "~=" compatible version operator. The implied comparison
operator for date based versions is ">=".
- clarified that zeroes and leading zeroes are permitted and that they
should be sorted like numbers
- based on discussions with some of the Red Hat security folks, I
tweaked the direct URL references to *always* require a hash in the
URL, even when using HTTPS or SSH.
PEP 426 and PEP 459 are further away from finalisation, but we're
definitely getting closer to something I'm happy with.
The PEP 426 changes:
- many of the fields are gone, having moved to PEP 459 extensions
- this also allowed the notion of "essential dependency metadata"
(with it's own separate filename) to go away
- the extension format changed to require a submapping
- extensions are now versioned (with an implied 1.0 if not specified)
- as with direct URLs in PEP 440, source URLs are now required to contain a hash
PEP 459 overview:
- standard extensions using the "python.*" namespace
- the details, project, exports and commands extensions just lift
several fields out of PEP 426
- the integrator extension is new, and matches the project extension
structure. It allows redistributors like a Linux distro or a Python
vendor to add their own info without overwriting the upstream project
- the new metadata_hooks extension replaces the install hooks design
in earlier drafts of PEP 426. In this new scheme, Twisted, for
example, would define an appropriate export group hook in order to be
told about any new extensions that exported Twisted plugins and take
In this revised metadata model, distributions *will* trigger their own
postinstall metadata hooks, but won't trigger their postuninstall
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
ok, so PEP459 has exports:
and distlib seems to be implementing them.
and "exports" seem to be entry points 2.0.
so theoretically, when PEP426/PEP459 becomes live....
what does that mean for setuptools-based projects? (I understand that we
might not have a clear idea now, but just trying to narrow down the
1) the setuptools "entry_points" keyword (and pkg_resources api) gets
re-implemented to understand PEP459 exports?
2) "entry_points" keeps the old implementation, and possibly tools are
written to handle the old and new metadata?
3) "entry_points" are stranded, and consumers have to rewrite setup.py
files to use some new keyword that understands PEP459
4) something altogether different...
as for why I'm asking, pip itself is considering command extensions, so
it's a direct practical matter for us.