| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Distutils2 will live on on PyPI and be included in the stdlib when it
is ready. See discussion starting at
http://mail.python.org/pipermail/python-dev/2012-June/120430.html
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The contents of this attribute are an implementation detail, as
documented for #9442, so we should not parse it, to support non-CPython
VMs with distutils2 in the future.
Unfortunately, one use comes directly from PEP 345, so an edit will have
to be agreed before fixing the code (see comment in p7g.markers).
Other remaining uses are found in p7g.compiler and could be replaced by
the platform module (which also parses sys.version, but then it wouldn’t
be my fault :)
|
| |
|
|
|
|
|
|
|
|
|
| |
This method was named reinitialize_command in distutils and accompanied
by a comment suggesting to change it to get_reinitialized_command.
Following that, I did the change for distutils2, but it proved
confusing: The Distribution object has an internal cache of command
objects, to make sure only one instance is ever used, and the name
get_reinitialized_command could suggest that the object returned was
independent of that cache, which it was not. I’m reverting the name
change to make code clearer.
|
| | |
|
| |
|
|
|
|
| |
There was already a test for this, but it was complicated and had a
subtle bug (custom command objects need to be put in dist.command_obj so
that other command objects may see them) that rendered it moot.
|
| |
|
