to an interesting resource:
http://www.lfd.uci.edu/~gohlke/pythonlibs/
(The security issues with that arrangement are non-trivial, but the
convenience factor is huge)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG
it and contribute with pulls and issues
Yes, a large part of my goal here is similar to that of the PSF board
when Brett Cannon was funded for a couple of months to write the
initial version of the CPython developer guide.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
that the access controls to a team's
repos all be the same.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On Thu, Mar 21, 2013 at 4:55 PM, Marcus Smith qwc...@gmail.com wrote:
and pypa needs a cool logo now...
If we were happy with something simple, a wheel of cheese bearing the
Python logo would be entirely appropriate :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
for the platform: pip install setuptools
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
(and it
likely won't be for 3.4 either), but that's where I would like us to
get to somewhere along the line.
On 25 March 2013 03:04, Nick Coghlan ncogh...@gmail.com wrote:
- once we can bootstrap pip, then bootstrapping easy_install if it
still needed for some edge cases will be as easy
its creator would like to see waved off into the sunset, giving thanks
for its good service :)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http
On Mon, Mar 25, 2013 at 9:23 AM, Nick Coghlan ncogh...@gmail.com wrote:
This can be handled in pip, by using the AST module to scan for
setuptools imports in setup.py (or else by checking for a setuptools
related ImportError after trying to run it). Yes, it's a hack, but I
am *not* going
inadvertently install setuptools on their
production systems if they don't want to).
To make this work, we'll need to get wheels published on PyPI for
setuptools before 3.4, as well as ensuring pip doesn't require
setuptools to install from wheel files.
Cheers,
Nick.
--
Nick Coghlan
a useful stepping stone to a
setup.py-is-optional future.
Cheers,
Nick.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
a source checkout/tarball (with
PKG-INFO.in) from an sdist (with PKG-INFO) from a wheel (with a named
.dist-info directory).
(For consistency, we may want to rename PKG-INFO to DIST-INFO in sdist
2.0, though)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
optional even for source installs,
but that requires further enhancements to the metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org
only dicts, lists and
strings as values.
previous will be the metadata for the version of the distribution
that was previously installed, if any.
Cheers,
Nick.
P.S. And now I'm leaving for the airport to fly home to Australia - no
more replies from me for a couple of days :)
--
Nick Coghlan
On 26 Mar 2013 21:08, Daniel Holth dho...@gmail.com wrote:
Yea, it's totally about keywords and that's just not an example of a
larger problem (like embedding little mini json documents) and what we need
is another competing standard all because of a legacy file format for a
file that barely
the existing post-install hook won't
run.
It's an interesting problem, but one where my near term plans amount
to document the status quo.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist
*, because the addition of new platform support needs to happen in
a more timely fashion than language releases. The incorporation of pip
bootstrapping into 3.4 will also make it a lot easier to recommend
more readily upgraded alternatives.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
/020207.html
for more on how this could be handled (consider mount/unmount as the
lower level API for actually adding new path entries directly to the
dynamic importer).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
be great.
Cheers,
Nick.
[1] http://bugs.python.org/issue1739468
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On Sat, Mar 30, 2013 at 6:42 AM, PJ Eby p...@telecommunity.com wrote:
On Fri, Mar 29, 2013 at 3:55 PM, Nick Coghlan ncogh...@gmail.com wrote:
No, mutating sys.path for versioned imports is a broken design. You
end up with two possibilities:
* If you append, then you can't override modules
On Sat, Mar 30, 2013 at 8:52 AM, PJ Eby p...@telecommunity.com wrote:
On Fri, Mar 29, 2013 at 4:50 PM, Nick Coghlan ncogh...@gmail.com wrote:
You don't lose the place where you want the inserts to happen. Without
the marker, you end up having to come up with a heuristic for make
insertions
to the simple metadata
will be cheap, because a TUF client would only download updated metadata. We
could amortize the initial simple metadata download cost by distributing it
with PyPI installers (e.g. pip).
Could we do better? Yes!
As Nick Coghlan has suggested, PyPI could begin adopting TUF
, but are
the worst case size.
OK, that makes sense - thanks for the clarification.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo
On 17 Apr 2013 00:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Vinay Sajip vinay_sajip at yahoo.co.uk writes:
I'm trying to move the distlib and pylauncher repositories to the PyPA
account on BitBucket. I'm getting Internal Server Errors with both
repos and
have logged an issue on
Richard (Jones, the main PyPI maintainer) has just returned from a
long business trip, so it may be a while before he catches back up
with distutils-sig.
I'll see if I can nudge some other folks and get you a better answer...
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
(with the on-disk serialisation format
changing to JSON).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
to address in the next draft. (My aim to get that posted
last week proved to be overly optimistic. Because this next update is
the key-value - JSON-compatible structured metadata switch, it's hard
to post a partial update and still have it even vaguely readable)
Cheers,
Nick.
--
Nick Coghlan | ncogh
On Thu, Apr 25, 2013 at 1:31 AM, Nick Coghlan ncogh...@gmail.com wrote:
Once the user guide and meta guide are in a better state, we'll update
the stdlib distutils docs with a reference to them as a guide to a
more up to date packaging toolchain.
Oops, I meant to echo Marcus' sentiment
guide are in a better state, we'll update
the stdlib distutils docs with a reference to them as a guide to a
more up to date packaging toolchain.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist
On 25 Apr 2013 05:38, Marcus Smith qwc...@gmail.com wrote:
* new (very incomplete) packaging guide for users
* new (very incomplete) working on packaging tools meta-guide for
contributors
Nick, btw, as I've started worked to work on these locally, I'm inclined
to just have one document
actually get there in a reasonable amount of time :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
I plan to reject PEP 390, since that feature won't be added to the stdlib.
The reason we will need at least a minimal replacement for it is so that
there's a standard place to define and retrieve the archiver hook that
creates the sdist (and hence pymeta.json) from a source tarball or VCS
to the relatively ad hoc
approaches in metadata 1.2, but it's still an ongoing challenge to
avoid runaway complexity.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
',
requires: [pywin32 (1.0)]
}
]
I definitely prefer separating out the conditional data from the
unconditional data, though - keep in mind that this spec also defines
the runtime API for accessing this info as structured metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On Fri, Apr 26, 2013 at 4:05 PM, PJ Eby p...@telecommunity.com wrote:
On Thu, Apr 25, 2013 at 9:50 PM, Nick Coghlan ncogh...@gmail.com wrote:
5. The installer evaluates the conditional metadata as appropriate
before writing the metadata out to the installation database and
invoking the post
to the bits that are metal. ;-) )
Keeping extensions (which will include entry points) in a separate
file is another potentially useful idea.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist
, which just says in a couple of places environment marker strings
can go here, and then defines the syntax for them once.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
metadata link API could
probably handle that in the long run).
It's not especially pretty, but it's better than having to use
os.listdir and rely on predefined file names.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 3 May 2013 03:09, Paul Moore p.f.mo...@gmail.com wrote:
Sorry, I knew that it installed to the per-user site packages directory,
but I never use that so I don't fully understand the implications.
But nevertheless, for my current usage, distil install foo is 99% of the
time a user error, as
On Fri, May 3, 2013 at 9:30 AM, Donald Stufft don...@stufft.io wrote:
On May 2, 2013, at 7:17 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 3 May 2013 09:08, Donald Stufft don...@stufft.io wrote:
On May 2, 2013, at 6:48 PM, Nick Coghlan ncogh...@gmail.com wrote:
pip --user manipulates
On 3 May 2013 11:39, Donald Stufft don...@stufft.io wrote:
On May 2, 2013, at 9:02 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Fri, May 3, 2013 at 9:30 AM, Donald Stufft don...@stufft.io wrote:
On May 2, 2013, at 7:17 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 3 May 2013 09:08
I would also be relatively happy for pip to refuse the temptation to guess
if run globally and require an explicit --user or --system whenever it is
run outside a virtual environment. However, I think it's better to make the
typical pip install whatever work for most unprivileged users without
On 4 May 2013 09:03, Carl Meyer c...@oddbird.net wrote:
Hi Nick
On 05/03/2013 12:14 PM, Nick Coghlan wrote:
I would also be relatively happy for pip to refuse the temptation to
guess if run globally and require an explicit --user or --system
whenever it is run outside a virtual
One of my major goals for metadata 2.0 is better packaging interoperability
with the Fedora and Debian ecosystems. Since those formally restrict the
set of permitted characters, and the existing Python packaging ecosystem
informally restricts it, it makes sense to limit the character set formally.
On Thu, May 16, 2013 at 10:00 AM, Donald Stufft don...@stufft.io wrote:
PyPI already endures case insensitive uniqueness and considers - and _ the
same for uniqueness checks
Still something we should formalise in the 2.0 spec, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
Very interesting!
The next draft of the metadata 2.0 spec is probably a couple of weeks away
from broader public consumption, at which time I'll be interested in
hearing whether or not that better meets DAF's needs (especially for
transitive dependency tracking).
(I haven't been putting the
a matter
of your preferences or other requirements.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
is why you haven't been able to find much specific info on
handling it.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils
improved packaging story start to come together...
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
, too :)
Agreed it would be a good number to publish once it's more readily
available, too.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org
/pep_drafts/pep-0440.txt?at=default
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
on that list.
So, as Holger said, great work and thanks for your efforts, but good
communication does matter with these things. People don't like
surprises, even well intentioned ones :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On Mon, May 27, 2013 at 9:36 PM, Nick Coghlan ncogh...@gmail.com wrote:
After preliminary reviews by Donald and Daniel, I have now pushed the
first complete draft of the JSON-based metadata 2.0 proposal to
python.org
PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/
PEP 440
.
Thoughts?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
will go away. Organization will be able to have any of the defined
roles (author, maintainer, contributor) and if we later decide we need
a programmatic means to distinguish abstract organisations from flesh
and blood humans we can consider adding a new mechanism.
Cheers,
Nick.
--
Nick Coghlan
, that's not actually the way
the mapping works anyway (development mode gets everything, not just
the dev dependencies).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
On Tue, May 28, 2013 at 12:44 AM, Ronald Oussoren
ronaldousso...@mac.com wrote:
On 27 May, 2013, at 13:36, Nick Coghlan ncogh...@gmail.com wrote:
After preliminary reviews by Donald and Daniel, I have now pushed the
first complete draft of the JSON-based metadata 2.0 proposal to
python.org
On Thu, May 30, 2013 at 12:32 AM, Daniel Holth dho...@gmail.com wrote:
On Wed, May 29, 2013 at 10:25 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, May 30, 2013 at 12:14 AM, Daniel Holth dho...@gmail.com wrote:
Request the test extra to also install
test_requires
test_may_require
On 30 May 2013 01:47, Daniel Holth dho...@gmail.com wrote:
In 440, 2.0 means 2.0, != 2.0.* to avoid dev releases. Would it be
equivalent for 2.0 to expand to the smallest possible release in the
2.0 series 2.0.dev0?
Yes, but that approach doesn't work to exclude post and maintenance
I'm with Jason in the maybe eventually, but not right now camp.
Namespace collisions are indeed a possibility and a potential concern, both
in the distribution namespace and the top level import namespace.
The fact there is no 1to1 mapping between distribution names and the import
namespace
collectively busy for a while
yet.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
not
to get compromised is already the status quo.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Great to hear!
Cheers,
Nick.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On 6 Jun 2013 04:49, Donald Stufft don...@stufft.io wrote:
On Jun 5, 2013, at 1:49 PM, Barry Warsaw ba...@python.org wrote:
On Jun 05, 2013, at 12:16 PM, Donald Stufft wrote:
Where are you updating the version information at? And how are you
generating
a tarball so that it's name has the
Yay, great news!
/me adds updating the packaging essay (both copies) to his TODO list :)
Cheers,
Nick.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
not to break such features without advance
warning and explicit consideration of alternatives that may allow us
to avoid the breakage in the first place.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG
to pip.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
it securely to the PSF
infrastructure team (at least for now)
If anyone has a better suggestion, please raise it.
As others have suggested, we should work with Donald and Noah to get
the bootstrapping script an official home somewhere on
pypi.python.org.
Cheers,
Nick.
--
Nick Coghlan | ncogh
On 10 June 2013 17:34, holger krekel hol...@merlinux.eu wrote:
On Mon, Jun 10, 2013 at 11:35 +1000, Nick Coghlan wrote:
On 10 June 2013 06:04, Alex Clark acl...@aclark.net wrote:
Donald Stufft donald at stufft.io writes:
So yes. I broke Download counts because they were not more important
maintained package approach is highly desirable there.
The only trick would be ensuring the pip wheel console script doesn't
collide with the bootstrap script, but worst case, we just special
case that directly in pip.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
download the wheel, add it directly to
the front of sys.path (as Paul suggested), import pip.main from there
and then use that to install pip itself before continuing with the
rest of the installation (still using the copy from the wheel for that
initial invocation).
Cheers,
Nick.
--
Nick Coghlan
Installs from the given wheel file instead of
downloading from PyPI
Linux distros could then patch the 'pip3 bootstrap --system' variant
to invoke the appropriate platform specific installation command.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
hole in the latest draft that Daniel, Donald and I missed.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On 20 June 2013 23:36, Daniel Holth dho...@gmail.com wrote:
On Thu, Jun 20, 2013 at 9:07 AM, Nick Coghlan ncogh...@gmail.com wrote:
The only major remaining open item is the addition of guidelines in
Appendix A for converting legacy metadata to metadata 2.0. I consider
the rest of the spec
missing something?
If setup.py test works for a distribution today, it will still work under
PEP 426. Anything more is deliberately deferred (as noted in the PEP).
Cheers,
Nick.
best and thanks for your good work,
holger
On Thu, Jun 20, 2013 at 23:07 +1000, Nick Coghlan wrote:
New versions
On 21 Jun 2013 06:19, holger krekel hol...@merlinux.eu wrote:
On Fri, Jun 21, 2013 at 01:05 +1000, Nick Coghlan wrote:
On 21 Jun 2013 00:36, holger krekel hol...@merlinux.eu wrote:
I still think the testing part of the interchange format
between software publication and integration
On 21 Jun 2013 07:40, Paul Moore p.f.mo...@gmail.com wrote:
On 20 June 2013 21:54, Daniel Holth dho...@gmail.com wrote:
These metadata PEPs are
mostly about the installer, database of installed files, and package
indexes.
In essence (and I freely admit I don't fully understand the details
arbitrary files to the dist-info directory and have them propagate
through the wheel files and all the way to the installation database.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist
On 20 June 2013 23:07, Nick Coghlan ncogh...@gmail.com wrote:
New versions of PEP 426 and PEP 440 are up on python.org:
PEP 426 (metadata 2.0): http://www.python.org/dev/peps/pep-0426/
PEP 440 (version spec): http://www.python.org/dev/peps/pep-0440/
(as before, not including them inline due
On 23 Jun 2013 21:09, Paul Moore p.f.mo...@gmail.com wrote:
On 23 June 2013 08:05, Nick Coghlan ncogh...@gmail.com wrote:
PEP 426 has now been updated based on the feedback on this thread (and
to handle some todo items that were pending anyway):
http://hg.python.org/peps/rev/3f733fe7c06c
that - this is what pip will do when
caching builds anyway, so we may as well be explicit that if
developers want code to run on target systems, they're going to have
to adopt metadata 2.0 install hooks)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 25 Jun 2013 22:47, Cédric de Saint Martin cedric@gmail.com wrote:
On 24 juin 2013, at 23:24, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/2013 05:06 PM, Reinout van Rees wrote:
Uninstalling distribute? Nice for those with
On 26 Jun 2013 05:50, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I would find it helpful to understand the motivation for direct
references as
defined in PEP 440, and some clarifications of how they can be used. For
example:
* Can they be used together with other clauses? As PEP 440 appears
On 26 Jun 2013 08:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
While the intended use case is to pin a specific version, you could also
use a more general latest link and use other clauses to trigger an
error when the version changes beyond
associated
info is handed over as a requirements specification, it has been
converted to a specific version number. It isn't distlib's problem
whether that was extracted from the URL directly, or by downloading it
and looking at (or possibly even generating) the metadata.
Cheers,
Nick.
--
Nick
itself.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
On 28 June 2013 00:15, Donald Stufft don...@stufft.io wrote:
On Jun 27, 2013, at 7:24 AM, Nick Coghlan ncogh...@gmail.com wrote:
It occurs to me, though, given that we now have an exact prefix
matching notation for more unusual forward compatibility constraints,
we *could* just make all
the common 2/3 subset of the
language.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
(these are distributions
that don't have any code of their own - they just declare dependencies
on other projects to make them easy to install as a group, or to
define the default provider for a dependency that may be satisfied by
any one of multiple distributions).
Cheers,
Nick.
--
Nick Coghlan | ncogh
On 30 June 2013 17:44, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Donald has been continuing his data modelling work for Warehouse (aka
PyPI 2.0: https://github.com/dstufft/warehouse) and found that the
*_requires/*_may_require split for dependencies
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian product with
the extras. You can define :meta:, :run:, :test:, :build: and :dev:
dependencies for any extra. So if, for example
On 1 Jul 2013 08:40, Gabriel de Perthuis g2p.c...@gmail.com wrote:
On Sun, 30 Jun 2013 21:21:54 +1000, Nick Coghlan wrote:
On 30 June 2013 18:53, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
No, because the semantic dependencies form a Cartesian
://wheel.readthedocs.org/en/latest/ to obtain the bdist_wheel command.
There's also the problem of hosting for the setuptools pip bootstrap
scripts. I believe the plan is to host it at a canonical URL on
pypi.python.org, but I'm not sure of the current status of that.
Cheers,
Nick.
--
Nick Coghlan | ncogh
figuring out the details of those APIs is some
time away. Note that the version currently referenced from the PEP is a
little out of date (
http://mail.python.org/pipermail/distutils-sig/2013-June/021357.html). I
will hopefully get it updated at the PyCon AU sprints next week.
Cheers,
Nick.
--
Nick
On 4 Jul 2013 18:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
* install: the installation specifier for the dependency
* extra: as per the current PEP (for conditional dependencies)
* environment: as per the current PEP (for conditional
On 4 Jul 2013 21:35, Donald Stufft don...@stufft.io wrote:
On Jul 4, 2013, at 7:00 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 4 Jul 2013 18:52, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
* install: the installation specifier
On 4 Jul 2013 22:32, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
I would prefer a single entry. It makes the serialization format map to
the
modeling simpler, and I think it's simpler for humans too. I don't see
much
benefit to making it a list
On 6 Jul 2013 04:08, Jason R. Coombs jar...@jaraco.com wrote:
The PyPA is excited to announce the public release of Setuptools 0.8.
This release of setuptools provides no additional functionality over
Setuptools 0.7.x except that it no longer requires 2to3 to build/install on
Python 3. What this
On 11 Jul 2013 04:56, Brett Cannon br...@python.org wrote:
On Wed, Jul 10, 2013 at 12:11 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 10 July 2013 15:28, Brett Cannon br...@python.org wrote:
So, at present, if I (as a 100% Python 3 user) want to install a
package, I type pip install XXX.
On 12 July 2013 15:11, Nick Coghlan ncogh...@gmail.com wrote:
In particular, it establishes the infrastructure to have pyvenv
automatically bootstrap the installer into each venv, even when it isn't
installed system wide (which is the key missing feature of pyvenv relative
to virtualenv
On 12 Jul 2013 18:36, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Donald Stufft donald at stufft.io writes:
We should remember that in general people have considered PyEnv that
ships
with Python 3.3 an inferior alternative to virtualenv largely in part
because they have to fetch setuptools
101 - 200 of 1528 matches
Mail list logo
