On 8 Nov 2013 08:44, Richard Jones r1chardj0...@gmail.com wrote:
Because (distutils history) it's currently not possible to python
setup.py upload using the secure HTTPS URL of PyPI. It is possible using
twine* which I'd like to promote at:
https://pypi.python.org/pypi(in the Package
On 17 Nov 2013 08:07, Donald Stufft don...@stufft.io wrote:
Wheels are way faster for pure python though, so they should totally be
uploaded :D
In chatting to someone proposing a patch for IPython to start publishing
wheels, I noted that wheels don't yet work even for distributions with
On 17 November 2013 14:05, Donald Stufft don...@stufft.io wrote:
On Nov 16, 2013, at 8:58 PM, Nick Coghlan ncogh...@gmail.com wrote:
The specific case affecting IPython was the need to define platform
dependent dependencies. Metadata 2.0 will handle that, but isn't going to
be
available until
It's covered in the PEP (including the venv module API changes):
http://www.python.org/dev/peps/pep-0453/#changes-to-virtual-environments
Associated (more concise) issue: http://bugs.python.org/issue19552
I aim to implement that later this week, but wouldn't complain is someone
beat me to a
To answer your other question, no, you cannot use ensurepip as if it was an
uninstalled pip, and this is a deliberate limitation to control the
complexity and compatibility requirements. If you want something like that,
install pip globally and run it with root set to the base of the venv
(that's
On 19 Nov 2013 03:20, Donald Stufft don...@stufft.io wrote:
On Nov 18, 2013, at 11:54 AM, Barry Warsaw ba...@python.org wrote:
Are you planning on putting a REST API on Warehouse?
Eventually, but the primary goal right now is feature parity with PyPI
legacy.
Some details of the REST API
Anatoly, the target audience for this doc is the Warehouse developers and
the PSF infrastructure team, not end users.
The end user docs will come later.
Cheers,
Nick.
___
Distutils-SIG maillist - Distutils-SIG@python.org
On 23 Nov 2013 02:32, Stefan Krah ste...@bytereef.org wrote:
[I'm not subscribed, could you please cc me?]
Hi,
On the danger of sounding like a broken record: PyPI displays
incorrect download counts (0) for external packages.
Would it be possible to skip the download count entirely for
On 24 Nov 2013 00:58, Paul Moore p.f.mo...@gmail.com wrote:
On 22 November 2013 17:06, Justin Cappos jcap...@nyu.edu wrote:
unclaimed project. What's this? What is the process of claiming a
project? Is there a better terminology? This reads like picking
abandoned
project or project without
On 25 Nov 2013 08:09, Stefan Krah ste...@bytereef.org wrote:
Nick Coghlan ncogh...@gmail.com wrote:
Would it be possible to skip the download count entirely for
external packages?
UI changes for the existing PyPI web service are low priority at the
moment, as
development efforts
release.
One key advantage of this model is that I'm proposing for the
extensions to be independently versioned, so we'd only have to update
the main metadata PEP in order to change the essential dependency
resolution metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
On 28 Nov 2013 23:18, Nick Coghlan ncogh...@gmail.com wrote:
It's (very) early days at this point, but I've taken the first steps
towards breaking up the metadata 2.0 monolith into multiple relatively
independent metadata extensions:
https://bitbucket.org/pypa/pypi-metadata-formats/commits
by default due to the
associated permissions restrictions, so the primary resolution still
needs to be for conda to correctly handle that situation and convert
the venv Python to a copy rather than failing)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 2 Dec 2013 06:48, Paul Moore p.f.mo...@gmail.com wrote:
On 1 December 2013 19:21, Marcus Smith qwc...@gmail.com wrote:
sometimes mean needing to build components with external dependencies
from source
you mean build once (or maybe after system updates for wheels with
external
binary
,
On 2 Dec 2013 01:04, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
On Sun, 1/12/13, Nick Coghlan ncogh...@gmail.com wrote:
(pyvenv doesn't offer an --always-copy option, just the option to use
symlinks on
It does - you should be able to run pyvenv with --copies to force
copying, even
On 2 December 2013 09:38, Paul Moore p.f.mo...@gmail.com wrote:
On 1 December 2013 22:17, Nick Coghlan ncogh...@gmail.com wrote:
For example, I installed Nikola into a virtualenv last night. That required
installing the development headers for libxml2 and libxslt, but the error
that tells you
On 2 Dec 2013 21:57, Paul Moore p.f.mo...@gmail.com wrote:
On 2 December 2013 10:45, Oscar Benjamin oscar.j.benja...@gmail.com
wrote:
Nick's proposal is basically incompatible with allowing Cristoph
Gohlke to use pip and wheels. Christoph provides a bewildering array
of installers for
On 3 Dec 2013 02:01, Imran M Yousuf im...@smitsol.com wrote:
Thanks for the suggestion Paul. Wheel structures exactly as I want it
to be, but I see it does not generate the entry point scripts; any
idea how to get them to work?
Those are platform dependent, so the installer generates them at
On 3 Dec 2013 00:19, Paul Moore p.f.mo...@gmail.com wrote:
On 2 December 2013 13:38, Tres Seaver tsea...@palladion.com wrote:
On 12/01/2013 06:38 PM, Paul Moore wrote:
I understand that things are different in the Unix world, but to be
blunt why should Windows users care?
You're
On 3 Dec 2013 08:17, Marcus Smith qwc...@gmail.com wrote:
publication of curated stacks when the conda folks already have one,
so, I see the index: http://repo.continuum.io/pkgs/index.html
Is they a way to contribute to this index yet? or is that what would
need to be worked out.
On 3 Dec 2013 09:03, Paul Moore p.f.mo...@gmail.com wrote:
On 2 December 2013 22:26, Nick Coghlan ncogh...@gmail.com wrote:
Whether solving the Unix
issues is worth it is the Unix users' call - I'll help solve the
issues, if they choose to, but I won't support abandoning the existing
Thanks for the robust feedback folks - it's really helping me to clarify
what I think, and why I consider this an important topic :)
On 3 Dec 2013 10:36, Chris Barker chris.bar...@noaa.gov wrote:
On Mon, Dec 2, 2013 at 5:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
And the conda folks
On 3 December 2013 19:22, Paul Moore p.f.mo...@gmail.com wrote:
On 3 December 2013 08:48, Nick Coghlan ncogh...@gmail.com wrote:
This means that one key reason I want to recommend it for the cases where it
is a good fit (i.e. the scientific Python stack) is so we can explicitly
advise *against
On 3 December 2013 20:19, Nick Coghlan ncogh...@gmail.com wrote:
Only folks that actually understand the difference between
static and dynamic linking and wrapper modules vs self-contained
accelerator modules are likely to understand what shared external
binary dependency means, so I agree
On 3 December 2013 19:11, Paul Moore p.f.mo...@gmail.com wrote:
On 3 December 2013 08:48, Nick Coghlan ncogh...@gmail.com wrote:
And wouldn't it be better to make wheel a bit more robust in this regard
than add yet another recommended tool to the mix?
Software that works today is generally
/setuptools
That will allow it to be made in a way that supports Python 2.6+,
whereas a distutils change won't really help anyone.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
though, since that's what I plan to
reference from the Python 3.4 docs. Even if it's incomplete, it would
be difficult for it to be more misleading than the current distutils
docs that are shipping with CPython :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 3 December 2013 22:49, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 3 December 2013 11:54, Nick Coghlan ncogh...@gmail.com wrote:
I believe helping the conda devs to get it to play nice with virtual
environments is still a worthwhile exercise though (even if just by
pointing out
On 4 Dec 2013 05:54, Marcus Smith qwc...@gmail.com wrote:
If conda doesn't offer such an internal consistency guarantee for
published package sets, then I agree with the criticism that it's just
an alternative to running a private PyPI index server hosting wheel
files pre-built with
format issue tracker:
https://bitbucket.org/pypa/pypi-metadata-formats/issue/13/add-a-new-subdirectory-to-allow-wheels-to
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
we're trying to minimise the number of
cases where they're needed.
Another possibility is that the pip/wheel/PyPI/metadata system can be
changed to allow a variant field for wheels/sdists. This was also
suggested in the same thread by Nick Coghlan:
https://mail.python.org/pipermail/distutils-sig
is that the pip/wheel/PyPI/metadata system can be
changed to allow a variant field for wheels/sdists. This was also
suggested in the same thread by Nick Coghlan:
https://mail.python.org/pipermail/distutils-sig/2013-August/022432.html
The variant field could be used to upload multiple variants e.g.
numpy
emulation that was all that was available in
versions prior to 3.3 can certainly be a bit fragile at times. The
native namespace packages in 3.3+ should be more robust (although even
one package erroneously including an __init__.py file can still cause
trouble).
Cheers,
Nick.
--
Nick Coghlan
On 5 December 2013 19:40, Paul Moore p.f.mo...@gmail.com wrote:
On 4 December 2013 23:31, Nick Coghlan ncogh...@gmail.com wrote:
Hmm, rather than adding complexity most folks don't need directly to the
base wheel spec, here's a possible multiwheel notion - embed multiple
wheels with different
On 4 December 2013 23:25, Daniel Holth dho...@gmail.com wrote:
On Wed, Dec 4, 2013 at 6:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding custom installation directories ==
This technically came up in the cobblerd thread (regarding installing
scripts to /usr/sbin instead of /usr/bin
a network directory).
To avoid having the implicit namespace packages in 3.3+ cause any
problems with this approach, the SSE subdirectories should contain
__init__.py files that explicitly raise ImportError.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 6 December 2013 17:10, Thomas Heller thel...@ctypes.org wrote:
Am 06.12.2013 06:47, schrieb Nick Coghlan:
Hmm, I just had an idea for how to do the runtime selection thing. It
actually shouldn't be that hard, so long as the numpy folks are OK
with a bit of __path__ manipulation in package
On 6 December 2013 17:21, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Fri, Dec 6, 2013 at 6:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
With that approach, the existing wheel model would work (no need for a
variant system), and numpy installations could be freely moved between
machines
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding conda ==
In terms of providing an answer to the question Where does conda fit
in the scheme of packaging tools?, my conclusion from the thread is
that once a couple of security related issues are fixed (think PyPI
On 7 December 2013 00:05, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 6 December 2013 13:54, Nick Coghlan ncogh...@gmail.com wrote:
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
I think this is important enough to warrant a NumPy and the
Scientific Python stack
On 7 December 2013 03:44, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
I created a draft of this new section at
https://bitbucket.org/pypa/python-packaging-user-guide/pull-request/12/recommendations-for-numpy-et-al/diff
the *packaging
system's* point of view, but not necessarily from the *application's*
point of view.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org
As part of the docs clarification, I was planning to point out that such
layouts are almost always platform (and even distro) specific. That's still
a valid use case for sdist and wheel, though, so it makes sense to me to
document it properly.
My other related question is whether it's possible to
FWIW, tackling FHS compliance is one of the things I have in mind as being
suitable for a metadata 2.0 extension.
Because Mac OS X and Windows just bundle (almost) everything into the
application directory, FHS concepts simply don't map properly, so the
current best FHS compliant solution is to
harder to administer.
Perhaps rather than trying to be generic with a name like root, we
could just define an explicit fhs path?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils
On 10 Dec 2013 08:03, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/09/2013 04:40 PM, Antoine Pitrou wrote:
Is there a changelog?
https://bitbucket.org/pypa/setuptools/src/f4d6757ae9fa79df03ef6ed070ab8757707fe963/CHANGES.txt?at=default
Ah,
On 14 December 2013 04:01, Chris Withers ch...@simplistix.co.uk wrote:
Hmm, doesn't appear this got any response.
Where should I report it?
The setuptools issue tracker is at https://bitbucket.org/pypa/setuptools/
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
something like this at all, it
shouldn't be POSIX specific.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 21 December 2013 21:40, Paul Moore p.f.mo...@gmail.com wrote:
On 21 December 2013 10:57, Nick Coghlan ncogh...@gmail.com wrote:
And these are the generic directories that aren't necessarily Python
specific:
scripts: directory for script files.
data: directory for data files
extensions that exported Twisted plugins and take
appropriate action
In this revised metadata model, distributions *will* trigger their own
postinstall metadata hooks, but won't trigger their postuninstall
hooks.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 25 Dec 2013 04:14, Chris Barker chris.bar...@noaa.gov wrote:
On Mon, Dec 23, 2013 at 1:43 PM, Daniel Holth Agreed. My biggest
concern with this whole idea is that developers
(typically POSIX developers, but it applies equally to all) will
*think* they need something like sbin because
around
without spamming the list with more incomplete designs like my initial
attempt.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
On 28 December 2013 06:02, Chris Barker chris.bar...@noaa.gov wrote:
On Tue, Dec 24, 2013 at 2:28 PM, Nick Coghlan ncogh...@gmail.com wrote:
But that concept doesn't work on all platforms, so we should be careful
about isolating it.
Encapsulating that assumption is why I think the gnu
On 28 December 2013 16:00, Nick Coghlan ncogh...@gmail.com wrote:
On 28 December 2013 06:02, Chris Barker chris.bar...@noaa.gov wrote:
Then the python distro would map these to actual paths at install time: gnu
systems would map the gnu locations, Windows to Windows-appropriate
locations, OS-X
,
Nick.
P.S. That reminds me, I should redo the PyPI version compatibility
numbers for the latest PEP 440 draft - making pytz relatively easy to
convert was the main gain, but I suspect the overall compatibility
percentage will improve a little bit regardless.
--
Nick Coghlan | ncogh...@gmail.com
On 1 Jan 2014 06:58, Daniel Holth dho...@gmail.com wrote:
It's nice to have that split up into lots of more focused documents.
Yeah, I was really happy with how breaking things up into multiple
extensions worked out.
I'm still pondering the question of whether or not to aim for the updated
On 1 Jan 2014 20:58, Paul Moore p.f.mo...@gmail.com wrote:
On 31 December 2013 22:53, Marcus Smith qwc...@gmail.com wrote:
for #1, during installation, I imagine the new setuptools would build
the
sdist (and any entry_point declarations) using 2.0 metadata.
So assuming the package
On 1 Jan 2014 10:33, PJ Eby p...@telecommunity.com wrote:
On Sat, Dec 21, 2013 at 9:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
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
On 2 Jan 2014 03:59, PJ Eby p...@telecommunity.com wrote:
On Wed, Jan 1, 2014 at 9:39 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 1 Jan 2014 10:33, PJ Eby p...@telecommunity.com wrote:
I have only been skimming these so far, will comment more later, but I
just want to mention
on
the wiki up to date by hand. Perhaps something like Progamming
Language :: Python :: Standard Library?
Thoughts?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
On 3 Jan 2014 08:20, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I guess my question then is why do you
care? If 2to3 is run at install time then it's a
cost, but it's one-time and if you really care you can
always create your own wheel of the translated code or
something.
Because I've
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
On 9 Jan 2014 20:35, Donald Stufft don...@stufft.io wrote:
On Jan 9, 2014, at 4:29 AM, Bohuslav Kabrda bkab...@redhat.com wrote:
Hi all,
the wheel package format, as defined in pep 427 specifies, that wheel
name can contain an optional build tag [1]. This build tag is supposed to
be a
On 15 Jan 2014 17:15, Marcus Smith qwc...@gmail.com wrote:
Fyi, the Python Packaging User Guide has moved from bitbucket to github.
The new project home is here:
https://github.com/pypa/python-packaging-user-guide
and the built site is still here:
On 16 Jan 2014 02:24, Paul Moore p.f.mo...@gmail.com wrote:
Metadata 2.0 doesn't support versions that are a single number.
Yes it does - that was one of the compatibility changes I made quite some
time ago. It's also listed as one of the differences relative to PEP 346.
The only things
On 16 Jan 2014 05:30, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
fair question. partly due to personal comfort level with git/github,
but also was
hoping we'd get more involvement using github, since it's more popular.
Your choice, of course, and I understand about the personal preference
On 16 Jan 2014 10:03, Marcus Smith qwc...@gmail.com wrote:
My apologies. I misread N[.N]+ as the '+' meaning one or more (as in
maybe N[(.N)+] would be clearer.
all of (.N)+ is optional
but when it's present it can be .N or .N.N or .N.N.N etc...
Yeah, that's a good idea. Simply
On 16 Jan 2014 18:08, Paul Moore p.f.mo...@gmail.com wrote:
On 16 January 2014 01:25, Chris Jerdonek chris.jerdo...@gmail.com wrote:
Is there a description somewhere of the plan for what
packaging-related information will be covered in docs.python.org
proper (and the stages for getting
On 17 Jan 2014 23:22, Matthew Iversen teh@gmail.com wrote:
On 17/01/14 13:52, Hannes Schmidt wrote:
I read through the Removing dependency_links thread [1] and I beg you
not follow through with the deprecation and removal of dependency_links and
to rethink your approach.
The mentioned
On 18 Jan 2014 04:45, Hannes Schmidt han...@ucsc.edu wrote:
Thank you for your suggestions, Donald. They are both feasible but they
feel like workarounds to me.
Manually listing transitive dependencies seems like a step backwards to
me. Isn't the whole point of setuptools/distutils that each
On 18 Jan 2014 10:29, Donald Stufft don...@stufft.io wrote:
I haven't used --find-links yet so I may be wrong but tarring up
packages and serving them by a web server is additional work that I'd
rather avoid. It just creates yet another copy of the package and requires
maintaining an additional
The problem is that sys.implementation is relatively new, so there's no
standard way to retrieve the implementation version prior to that addition
to the language spec. I agree the PEP should be explicit that that tag
needs to reflect the implementation's *ABI* stability, which may or may not
different SSE modules.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 24 Jan 2014 08:03, Chris Barker chris.bar...@noaa.gov wrote:
On Thu, Jan 23, 2014 at 12:25 PM, Thomas Heller thel...@ctypes.org
wrote:
Did I say this before? I would suggest that numpy develops a way
where all the SSE binary variations would be installed, and the
appropriate ones be
On 24 Jan 2014 19:41, Paul Moore p.f.mo...@gmail.com wrote:
On 24 January 2014 00:17, Oscar Benjamin oscar.j.benja...@gmail.com
wrote:
You need to bear in mind that people currently have a variety of ways
to install numpy on Windows that do work already without limitations
on CPU
then with e.g. `pip install --index-url
https://testpypi.python.org/pypi numpy`, and see what tends to break or what
doesn't.
And yes, using testpypi to experiment with wheels is a good idea.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
Paul's position exactly mirrors my own - I an perfectly fine with the
recommended advice to scientific users continuing to be NumPy doesn't
officially support pip and virtualenv because of the way it is built and
installed, so you will have to get one of the curated scientific stacks,
bootstrap
On 26 Jan 2014 09:51, Richard Jones rich...@python.org wrote:
Thanks everyone who helped make this happen.
Indeed - fine work! :)
From my perspective* I believe the ssh upload mechanism was added to
address security issues around the basic-auth-over-http method used
historically. Now uploads
the ABI
compatibility requirements properly.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
throwing ;)
I know it's a rather complex spec, but robust and comprehensive
versioning is a rather complex problem :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
definitely supposed to be allowed by the spec, specifically for that
ctypes/cffi style use case. Now, whether the tools currently provide a way
to *generate* a tag like that is a different question :)
Cheers,
Nick.
On Tue, Jan 28, 2014 at 5:40 AM, Nick Coghlan ncogh...@gmail.com wrote:
Currently
I think you're reading too much into that comment. Putting a wheel file
directly on sys.path is no different from putting any other zipfile
directly on sys.path - whether or not it will work depends on the context,
but it's a useful capability if used responsibly (as we do in the ensurepip
On 29 Jan 2014 11:19, Daniel Holth dho...@gmail.com wrote:
On Tue, Jan 28, 2014 at 7:18 PM, Donald Stufft don...@stufft.io wrote:
On Jan 28, 2014, at 6:38 PM, Nick Coghlan ncogh...@gmail.com wrote:
I think you're reading too much into that comment. Putting a wheel file
directly
All of those arguments are against *recommending* directly importing
from wheels. Yes, there are lots of problems with running directly
from a zip archive, which is why the fact that easy_install *actively
encourages* potentially inexperienced users to run things that way is
so problematic.
to refer specifically to SciPy :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
compatibility requirements, and removing experimental
APIs that we later decided we weren't happy with could prove
problematic.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
).
You can campaign to deprecate that feature *if* we ever want to make a
change to the wheel format that is incompatible with it.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils
it.
=
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 29 January 2014 23:10, Paul Moore p.f.mo...@gmail.com wrote:
On 29 January 2014 12:58, Nick Coghlan ncogh...@gmail.com wrote:
You can campaign to deprecate that feature *if* we ever want to make a
change to the wheel format that is incompatible with it.
Note that virtualenv uses
we discussed, and I know what PEP I
approved. Trying to play gotcha with links *isn't going to work*.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https
of zipimport compatibility.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
compatible was a deliberate feature, so it was a surprise to me when
Armin Ronacher said in his recent article that it wasn't supported
(and hence the clarification).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
generally prefer approaches that work seamlessly with C
extensions as well.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo
On 30 Jan 2014 00:28, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
It may be useful to understand that wheel has *political features* or
if you prefer *setting the defaults based on what we have learned from
eggs*. I don't recommend that they be zip-imported generally
but if you are a
On 30 Jan 2014 07:50, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Nick Coghlan wrote:
Otherwise we'd have to define a whole new format for something that
can be adequately handled by a wheel that meets certain restrictions,
and that would be pointless (we already have too many formats
I have clearly done a bad job so far of explaining the clarification in PEP
427, so here's a new attempt that relies solely on the PEP text and the way
the import system works, rather than the fact that the discussions around
the PEP show that the import system compatibility was a deliberate
But that's what I'm saying, there are only three ways to break this
behaviour:
1. Changing the wheel format in such a way that we drop support for being
able to install simple wheel files without a specialised installer
2. Break zipimport itself to explicitly disallow wheel files
3. Switch to a
On 30 Jan 2014 15:27, Donald Stufft don...@stufft.io wrote:
I can't believe folks are unable to differentiate between the difference
of
It's possible to do so because we didn't actively attempt to prevent it
and
This is a documented goal of the format and thus must be considered as
part of
the
401 - 500 of 1528 matches
Mail list logo
