, but you're right, in a server
context, IPv6 only is far more likely to be viable already.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
On 13 Jun 2014 02:01, Donald Stufft don...@stufft.io wrote:
Not currently. There’s an open issue about how to handle that within
Wheels as a few projects need those kinds of hooks.
To elaborate a little further on that, install time scripts are one of the
main motivators for required extensions
of build dependencies that is
part of the metadata 2.0 definition). Donald could provide a better
update than I can in terms of the current status of the Warehouse
migration, and the remaining blockers.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
somewhere?
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 29 Jun 2014 07:29, Jim Fulton j...@zope.com wrote:
You also don't need tools to automate deployment of production
configurations when an application is deployed, as this is mostly done
when building an image. The isolation provided by docker containers
also allows configuration to be
On 3 July 2014 03:24, Reinout van Rees rein...@vanrees.org wrote:
On 30-06-14 17:56, Nick Coghlan wrote:
Yeah, it's the you still need a way to define what goes into the image
part that intrigues me with respect to combining tools like zc.buildout
with Docker.
Buildout, to me, solves all
On 14 Jul 2014 17:11, Erik Bray erik.m.b...@gmail.com wrote:
Still, if anyone else has further thoughts on this topic I'd be
interested.
Twisted still has the most sophisticated approach to NEWS files I've seen:
https://twistedmatrix.com/trac/wiki/ReviewProcess#Newsfiles
The upcoming PEP 459
On 17 Jul 2014 05:28, Richard Jones rich...@python.org wrote:
Thanks for the feedback, Josh.
The Python 3 version of the distutils documentation is far improved on
this topic, I believe (though please, file a bug / change if you can
improve it :)
On 17 Jul 2014 15:10, Paul Moore p.f.mo...@gmail.com wrote:
Longer term, maybe your use case is something that we could support
via Metadata 2.0.
For the record, the current draft of the python.commands extension in PEP
459 does indeed include support for reporting prebuilt commands:
On 17 Jul 2014 16:15, David Genest david.gen...@ubisoft.com wrote:
For the record, the current draft of the python.commands extension in
PEP 459 does indeed include support for reporting prebuilt
commands:
http://www.python.org/dev/peps/pep-0459/#the-python-commands-extension
The draft
and
distutils.
Woohoo! Just knowing you're working on it is helpful - it's one of the
big items on my wishlist that I couldn't even consider writing myself,
since I don't know setuptools *or* distutils anywhere near well enough
:)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
On 24 Jul 2014 03:09, Richard Jones r1chardj0...@gmail.com wrote:
I believe the current PEP addresses the significant usability issues
around this by swapping them for other usability issues. In fact, I believe
it will make matters worse with potential confusion about which index hosts
what,
On 25 Jul 2014 02:05, Donald Stufft don...@stufft.io wrote:
Sorry, I think the provides functionality is outside of the scope of what
we would use TUF for. It is *only* respected if you have that project
installed. In other words if there is a package “FakeDjango” which provides
“Django”, then
On 25 Jul 2014 17:46, Chris Withers ch...@simplistix.co.uk wrote:
On 24/07/2014 17:44, Daniel Holth wrote:
Also, reject uploads that are not released under a DFSG license
What's a DFSG license
or lack
man pages.
Are you serious?
I took it as a sarcastic comment cryptically expressing
externally hosted version.
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 25 July 2014 23:34, Donald Stufft don...@stufft.io wrote:
On July 25, 2014 at 9:29:14 AM, Richard Jones (r1chardj0...@gmail.com)
wrote:
On 25 July 2014 15:21, Nick Coghlan ncogh...@gmail.com wrote:
On 25 July 2014 23:13, Richard Jones r1chardj0...@gmail.com wrote:
A variation
On 26 Jul 2014 05:56, Donald Stufft don...@stufft.io wrote:
On July 25, 2014 at 3:50:30 PM, Wichert Akkerman (wich...@wiggy.net)
wrote:
Will that guarantee the OS-provided Python was used? Or is there still a
risk someone was using a custom compiled Python on an Ubuntu 14.04 system
that is not
commits). Users don't have to
mess about manually figuring out how to build extensions against a
different version of CPython, they can just use the SCL utilities.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 26 July 2014 18:28, Ronald Oussoren ronaldousso...@mac.com wrote:
On 26 Jul 2014, at 08:54, Nick Coghlan ncogh...@gmail.com wrote:
Yes, by system Python on Linux, I mean the distro provided one.
(Technically Apple provide one as well, but binary compatibility there
is still governed
no generally accepted technique for automating
it at this point (Although there's an issue open suggesting the
addition of a feature along these lines to devpi:
https://bitbucket.org/hpk42/devpi/issue/110/build-put-wheel-for-pypi-released-package)
Cheers,
Nick.
--
Nick Coghlan | ncogh
On 29 Jul 2014 03:43, Giovanni Bajo ra...@develer.com wrote:
Hello,
on March 2013, on the now-closed catalog-sig mailing-list, I submitted a
proposal for fixing several security problems in PyPI, pip and
distutils[1]. Some of my proposals were obvious things like downloading
packages through
On 29 Jul 2014 10:01, Giovanni Bajo ra...@develer.com wrote:
Il giorno 29/lug/2014, alle ore 01:36, Nick Coghlan ncogh...@gmail.com
ha scritto:
On 29 Jul 2014 03:43, Giovanni Bajo ra...@develer.com wrote:
Hello,
on March 2013, on the now-closed catalog-sig mailing-list, I submitted
On 29 July 2014 11:50, Ian Cordasco graffatcolmin...@gmail.com wrote:
On Mon, Jul 28, 2014 at 8:12 PM, Giovanni Bajo ra...@develer.com wrote:
Il giorno 29/lug/2014, alle ore 02:39, Nick Coghlan ncogh...@gmail.com ha
scritto:
If your PEP defends against all the attacks TUF does
On 12 Aug 2014 01:23, Donald Stufft don...@stufft.io wrote:
On Aug 11, 2014, at 11:11 AM, Marcus Smith qwc...@gmail.com wrote:
Public index servers SHOULD NOT allow the use of local version
identifiers for uploaded distributions.
I'm thinking this should just say PyPI and not Public
have it’s own name and version
numbers I think?
Agreed. For use of the local version field to be appropriate, we
should be looking at full API compatibility with the public version
identifier.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
of Python :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
in June 2009, more than five years ago!
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 28 Aug 2014 05:56, Daniel Holth dho...@gmail.com wrote:
Tell me more about setup-requires. It's nice to hear it has users. Should
we promote it to a pypa project?
That would be cool - bootstrapping as much as we can *without* metadata 2.0
has the virtue of working in many more environments
On 29 Aug 2014 08:27, Donald Stufft don...@stufft.io wrote:
Just thought of this, if the normalized name doesn’t match the real
name,
then add entries for both. This will make it so that pip 1.5 continues to
work
and pip 1.6+.
Having bandersnatch mirrors publish under both names sounds like
On 2 Sep 2014 03:19, Marcus Smith qwc...@gmail.com wrote:
My view is that Python packaging should not support installation of
files to anywhere other than subdirectories of the scheme [...]
For packages that need to install to absolute locations, I would
suggest that this be handled by a
environment where tests for pip,
bandersnatch and devpi were all automatically run against pypi commits
before they went live, but that's rather a lot of work to set up.
Until we have such a system, we may continue to see occasional
incidents like this one.
Cheers,
Nick.
--
Nick Coghlan | ncogh
for pointing it out!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
at this point is the lack of up to date jsonschema files. Getting
that out the door may be something to explore post pip 1.6)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG
to PEP 459.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
back my earlier comment about PEP 426 being almost
ready to go :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 13 Sep 2014 00:20, Paul Moore p.f.mo...@gmail.com wrote:
Yes, it sounds like things are getting complex here and I'm not sure I
follow why. At the moment, the metadata for a distribution is
generated when setup.py is run, and is stored in the wheel and in the
installed dist-info directory
(and sufficiently comprehensive).
2. It also meant they were *approved* together, in advance of the rest
of PEP 426. An agreed version numbering scheme on its own isn't
particular useful, without a way to use it to improve pkg_resources
style dependency declarations.
Cheers,
Nick.
--
Nick Coghlan
On 17 Sep 2014 03:02, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
From: Paul Moore p.f.mo...@gmail.com
One thing that might be worth clarifying somewhere/somehow (not
particularly in the specs, though) is where is the best place to find
the canonical implementations of the various
packaging/pip layer.
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 18 September 2014 10:08, Donald Stufft don...@stufft.io wrote:
On Sep 17, 2014, at 1:05 AM, Nick Coghlan ncogh...@gmail.com wrote:
Perhaps we should make that official policy? Anything in PEP 426 and
PEP 459 (and other packaging metadata and installation database
related PEPs) needs
What about an approach where pip first tries the canonical name, and if
that fails, tries the exact given name?
Seems to me like that should handle legacy mirrors without the big download.
Cheers,
Nick.
___
Distutils-SIG maillist -
On 18 Sep 2014 17:48, Nick Coghlan ncogh...@gmail.com wrote:
What about an approach where pip first tries the canonical name, and if
that fails, tries the exact given name?
And by canonical I mean normalised.
Seems to me like that should handle legacy mirrors without the big
download
don't know, I'm just tossing out some potentional ideas!
Yep, for this kind of thing, automate can be a better answer than
document - it's much easier to delegate (or otherwise hand over the
reins) when the process is built into the tools.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
to that team.
That's sort of what happens now - the requestor is *added* to the
admin list, but the previous maintainer remains as co-owner.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils
On 23 Sep 2014 00:19, Antoine Pitrou anto...@python.org wrote:
Donald Stufft donald at stufft.io writes:
PyPI inherinently has complete control over who owns what name on PyPI.
Political authority does not derive from technical control, though.
As Toshio said that are situations where
On 26 Sep 2014 01:15, David Cournapeau courn...@gmail.com wrote:
On Wed, Sep 24, 2014 at 7:49 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 24 September 2014 17:24, Chris Barker chris.bar...@noaa.gov wrote:
Thanks -- that would be great. But really, why is this so hard? Win64
is
://aka.ms/vcpython27
Wonderful news Steve, thanks!
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 29 Sep 2014 18:49, M.-A. Lemburg m...@egenix.com wrote:
You are missing out on cases, where the release process causes files to
be omitted, human errors where packagers forget to apply changes to
e.g. documentation files, version files, change logs, etc., where
packagers want to add
On 29 Sep 2014 19:04, M.-A. Lemburg m...@egenix.com wrote:
Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users who have already installed one
of the non-broken ones to upgrade
On 29 Sep 2014 19:50, Nick Coghlan ncogh...@gmail.com wrote:
On 29 Sep 2014 19:04, M.-A. Lemburg m...@egenix.com wrote:
Do you seriously want to force package authors to cut a new release
just because a single uploaded distribution file is broken for
some reason and then ask all users
On 29 Sep 2014 21:04, Donald Stufft donald.stu...@rackspace.com wrote:
On Sep 29, 2014, at 6:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
One caveat on this: it would potentially be convenient to have a
release field in the wheel naming scheme, and adopt a similar approach
for other binary
On 29 Sep 2014 21:20, holger krekel hol...@merlinux.eu wrote:
(Fixed quoting indent + some own comments)
On Mon, Sep 29, 2014 at 11:04 +, Donald Stufft wrote:
On Sep 29, 2014, at 6:01 AM, Nick Coghlan ncogh...@gmail.commailto:
ncogh...@gmail.com wrote:
It's the silent substitution
On 30 Sep 2014 00:43, Donald Stufft don...@stufft.io wrote:
Yea I don’t think PyPI needs anything for this, if someone wants to do it
they can use testpypi.python.org, or they can stand up a devpi instance
which offers a similar thing plus a lot more for a release process.
It occurs to me that
On 29 Sep 2014 22:09, Wichert Akkerman wich...@wiggy.net wrote:
On 29 Sep 2014, at 13:58, Nick Coghlan ncogh...@gmail.com wrote:
Right, this is my perspective as well. The point that the wheel format
already includes a build ordering field was significant because that file
naming scheme has
On 30 Sep 2014 19:06, M.-A. Lemburg m...@egenix.com wrote:
You're regularly bringing up this argument.
Let's just be fair here: external hosting of packages has been made so
user unfriendly in recent pip releases, that this has pretty much
become a non-option for anyone who wants to create a
index discovery.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
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@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 2 Oct 2014 06:12, Paul Moore p.f.mo...@gmail.com wrote:
On 1 October 2014 21:06, Daniel Holth dho...@gmail.com wrote:
You are confusing generated entry_points script wrappers with the
setup(scripts=...) scripts. The scripts=... scripts should never be
skipped, even with --skip-scripts,
or not to disable that support is
based on *looking at the numbers again* before turning the feature off
on the server, and perhaps also monitoring for user complaints for a
period after it is first turned off, before the feature is removed
from the clients.
Regards,
Nick.
--
Nick Coghlan | ncogh
being a quality of implementation issue rather than a hard
requirement).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo
On 5 October 2014 03:21, Donald Stufft don...@stufft.io wrote:
On Oct 4, 2014, at 3:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
So while PEP 470 would allow clients to *consider* dropping link
spidering support (and any new clients would be free to never add it),
it likely doesn't make sense
their infrastructure in a
dangerously insecure configuration. That has nothing to do with PEP
470.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
open source community.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
requested package to be
spelled out more clearly?
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 8 October 2014 20:57, holger krekel hol...@merlinux.eu wrote:
On Wed, Oct 08, 2014 at 20:27 +1000, Nick Coghlan wrote:
Well, for installing NAME from pypi you need to trust that the people
who registered and maintain NAME are not doing something bad (and the
machine is not compromised
private packages residing on the extra index.
That's what a default repository *does*. It's always on, unless you
explicitly turn it off. Hence the name *extra index*. The index URL
option is the one to use if you want to *replace* the index.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
included as an illustration of one of the reasons the
multi-index/alternative-index support already exists. If you find the
example distracting from the actual point of the PEP, then the example
isn't serving its purpose, and we're better off without it.
Regards,
Nick.
--
Nick Coghlan | ncogh
to pip and the PyPA in general when decided whether a
change can be handled within the scope of an individual project, or if
it needs to be escalated for broader discussion.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 8 Oct 2014 23:40, M.-A. Lemburg m...@egenix.com wrote:
The intention of PEP 435 was to enable pip to evolve independent
of the Python release process, which is a good thing.
However, your comment that We are an external project and we are not
bound by the PEP process. doesn't really pan
Download URL links over, rather than the scraped links.
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 12 October 2014 09:49, Donald Stufft don...@stufft.io wrote:
On Oct 11, 2014, at 7:48 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 12 October 2014 04:29, Donald Stufft don...@stufft.io wrote:
I plan to put the external repositories (and the commands needed to use
them)
in the UI
extra
for installing the project itself (to go along with the currently
proposed implicit extras for :meta:, :run:, :build:, :test:,
and :dev: to indicate which dependency lists to process).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 12 October 2014 21:54, Nick Coghlan ncogh...@gmail.com wrote:
On 12 October 2014 21:38, Paul Moore p.f.mo...@gmail.com wrote:
Is it possible to switch this round somehow, so that I have an extra
that *removes* some of the dependencies?
(I could have 2 projects, a core one and a cmdline one
On 12 Oct 2014 22:36, Paul Moore p.f.mo...@gmail.com wrote:
On 12 October 2014 13:04, Nick Coghlan ncogh...@gmail.com wrote:
Any thoughts on how I could do this?
I don't know of any current way to do it, and even the more flexible
extras notation in PEP 426 doesn't quite get you
On 15 Oct 2014 11:16, Donald Stufft don...@stufft.io wrote:
On Oct 14, 2014, at 8:50 PM, Stefan Krah stefank...@freenet.de wrote:
Anyway, it will be kind of tough to force U.S. exceptionalism via the
terms
and conditions on an international body of authors if only uploaded
packages
are
of the external hosting support). The previous
design in PEP 438 ended up failing on both of those counts, which is
why there is now this new proposal to replace it with a different
mechanism that has been designed to address the existing usability
challenges.
Regards,
Nick.
--
Nick Coghlan | ncogh
that is
currently delegated to anyone.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
install on 2.7 or 3.x
I'd be very wary of including technical requirements like this in the
package transfer process.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
downloading and discovering packages via PyPI, and developers
retaining autonomy in relation to how they choose to engage with the
intricacies of the global copyright system.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
- the thing you don't want on your production servers is
the compilers that setuptools needs in order to do anything useful
with extension module source files).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG
On 29 Oct 2014 01:02, David Cournapeau courn...@gmail.com wrote:
Practically speaking, there is no such a thing as ABI on Linux: even if
you somehow managed to deal with glibc, you would then need to deal with
fortran ABI, then with C++ ABI, etc... Dealing with this at the python
level is simply
On 30 Oct 2014 07:20, Marcus Smith qwc...@gmail.com wrote:
yes, I'm partial to a solution like this prior to wheel 2.0 (that I
imagine would support additional/custom tags)
+1 for being able to add additional custom platform tags in the file naming
convention from me as well. As Marcus noted
.
That way future standardisation can be based on experience rather than
trying to guess potential use cases in advance.
Cheers,
Nick.
On 30 October 2014 11:17, Donald Stufft don...@stufft.io wrote:
On Oct 29, 2014, at 7:57 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 30 Oct 2014 07:20
On 9 Nov 2014 22:28, Nick Coghlan ncogh...@gmail.com wrote:
On 9 Nov 2014 22:16, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Thanks, that's very useful feedback. I agree, the need for RDP is very
Windows-specific - I don't know how common RDP tools are for Unix
should be useful regardless of the specific version control
system.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils
.
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 28 November 2014 at 18:19, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 28 Nov 2014 16:03:59 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Here's my proposed change:
=
The default platform tag is distutils.util.get_platform() with all
hyphens - and periods . replaced
On 29 November 2014 at 01:31, Matthias Klose d...@ubuntu.com wrote:
On 11/28/2014 07:03 AM, Nick Coghlan wrote:
We've discussed the idea of changing the wheel file naming scheme to
deal with Linux previously, but never put together a concrete
proposal.
The closest we've got is the idea
On 29 November 2014 at 01:51, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 29 Nov 2014 01:27:44 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Is this not going to be a slippery slope?
Only if folks publish Linux binaries themselves, and that's still a
bad idea (for the same reason
On 30 November 2014 at 02:10, Antoine Pitrou solip...@pitrou.net wrote:
On Sun, 30 Nov 2014 01:47:16 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 29 November 2014 at 01:51, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 29 Nov 2014 01:27:44 +1000
Nick Coghlan ncogh...@gmail.com wrote
usability issues (which become much harder to ignore once you're
working on secure package distribution infrastructure).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
API (as it's internal,
and I don't believe it's been designed for use as a library by external
code).
Agreed - the components intended for external use are the ones being
factored out into the packaging.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
on
Python 2.7.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
After an offline discussion with Donald regarding feedback on the
setuptools 8.0 release, I'm proposing we change the status of PEP 440 to be
Provisional (in the PEP 411 sense) until we sort out the additional issues
that were revealed through actual adoption.
I can't actually make that change to
things for someone,
somewhere. Those ecosystem specific constraints are thus far more
heavily weighted as a design consideration than interoperability with
third party versioning conventions (although we do aim to accommodate
those where practical).
Cheers,
Nick.
--
Nick Coghlan | ncogh
.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
describes here is valid (and should
work with setuptools 8 + pip 6), it isn't really the primary intended
use case - it's aimed at when you're installing Python packages but
using something other than the Python specific tooling to do it (e.g.
apt-get, yum, conda, etc).
Cheers,
Nick.
--
Nick Coghlan
for publication thus shouldn't break
anything on the consumption side.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils
On 18 Dec 2014 20:30, Olivier Grisel olivier.gri...@ensta.org wrote:
Since PEP 440 was formally accepted in August 2014, would it make
sense to add a change log to document the amendment of the PEP, for
instance in the appendix (maybe with a link to the diff in hg)?
Yeah, that's a good idea.
On 19 Dec 2014 03:50, Marcos Klein mkle...@gmail.com wrote:
I have two update requests for PEP 440.
Could PEP 440 date-based version identifier examples be extend to include
full timestamp version identifiers?
Sure, that's not a change to the semantics, just some additional examples.
This
601 - 700 of 1528 matches
Mail list logo
