will be at risk even if an attacker controls PyPI
and goes undetected for a month.
We thank Nick Coghlan and Donald Stufft for their valuable contributions,
and Giovanni Bajo and Anatoly Techtonik for their feedback.
Thanks,
PEP 458 480 authors
On 23 Dec 2014 19:02, Donald Stufft don...@stufft.io wrote:
On Dec 23, 2014, at 1:03 AM, Marcus Smith qwc...@gmail.com wrote:
oh, A compatible release clause consists of either a version identifier
without any comparison operator or else the compatible release operator ~=
On Mon, Dec 22,
On 24 Dec 2014 05:27, Marcus Smith qwc...@gmail.com wrote:
just post edit suggestions here?
https://bitbucket.org/pypa/pypi-metadata-formats is not up to date
anymore
some other location?
It *should* be being kept in sync with the published versions, but Donald
and I have just been working
On 25 Dec 2014 03:25, Marcus Smith qwc...@gmail.com wrote:
It *should* be being kept in sync with the published versions, but
Donald and I have just been working directly in the main PEP repo recently.
Hence my suggestion of moving it to GitHub - it's more likely to be kept
up to date there,
On 25 Dec 2014 06:51, Marcus Smith qwc...@gmail.com wrote:
Above, I used the word environment, which was just short hand for the
whole set of installed packages on the Python path for the interpreter used
by your application. This is often literally a virtual environment
created by
On 28 Dec 2014 17:12, Donald Stufft don...@stufft.io wrote:
On Dec 27, 2014, at 9:26 PM, Donald Stufft don...@stufft.io wrote:
On Dec 27, 2014, at 9:10 PM, Marcus Smith qwc...@gmail.com wrote:
In gives me a minor bit of pause. However any alternative that I can
come up
with bothers me
we found challenging in bringing PEP 440 to a close (this is the first PEP
completed under the new delegation of authority model, and we've definitely
found some rough edges that could stand to be smoothed out)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 29 December 2014 at 17:12, Marcus Smith qwc...@gmail.com wrote:
how about just pypa/peps for the name?
I would find the name clash with the main peps repo very annoying :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 30 December 2014 at 05:09, Chris Jerdonek chris.jerdo...@gmail.com
wrote:
On Mon, Dec 29, 2014 at 12:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
* for those cases (like date-based versions) where excluding releases
with
an additional numeric suffix is the right thing to do, an explicit
On 23 December 2014 at 04:15, Vladimir Diaz vladimir.v.d...@gmail.com
wrote:
On Mon, Dec 22, 2014 at 11:30 AM, Nick Coghlan ncogh...@gmail.com wrote:
From my perspective, the split into two PEPs meant most of the areas I
have doubts about have been moved to the end-to-end security model
.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
if it doesn't make it
into this initial update.
Regards,
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
attempting to teach humans to conform to the current needs of the
software.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 2 January 2015 at 16:38, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 1:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
That's the part I meant - the signing of developer keys to delegate trust
to them without needing to trust the integrity of the online PyPI service.
Hence
On 2 January 2015 at 16:13, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 12:57 AM, Nick Coghlan ncogh...@gmail.com wrote:
To raise the cost of a compromise through distributed signing authority,
we have to solve the trust management problem - getting developer keys out
to end
it with an account management
problem that they're likely to already be thoroughly familiar with, even if
they don't any experience in secure software distribution.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils
to offer a superior UX in a PEP
480 context, but I'm not pushing for a short term decision on that one -
I'm just aiming to plant the seeds of ideas that may be worth keeping in
mind as we work on PEP 458.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
.
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 3 January 2015 at 02:12, Donald Stufft don...@stufft.io wrote:
On Jan 2, 2015, at 10:51 AM, Nick Coghlan ncogh...@gmail.com wrote:
Getting them to manage additional keys, and get them signed and registered
appropriately, and then supplying them is going to be a similar amount of
work
developers
group).
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 31 December 2014 at 13:52, Nick Coghlan ncogh...@gmail.com wrote:
Donald is keen to get the updated versions of packaging/pip/setuptools out
that fix the regression in handling exclusive ordered comparison, so this
is a last call for feedback on those changes before we publish the updated
://pyospkg.readthedocs.org/en/latest/overview.html
Oh, very nice. I'm going to ping a few folks about taking a look at that :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https
about docker images - every project is
going to have a different special thing at some URL.
That's already part of the proposed project metadata extension in PEP 459.
Cheers,
Nick.
Thanks,
-- Ionel Cristian Mărieș, blog.ionelmc.ro
On Sun, Feb 1, 2015 at 2:43 AM, Nick Coghlan ncogh...@gmail.com
On 3 Feb 2015 19:10, Paul Moore p.f.mo...@gmail.com wrote:
On 1 February 2015 at 03:54, Nick Coghlan ncogh...@gmail.com wrote:
I agree that from an implementation perspective, this could just be a
new recommended URL in the project URLs metadata (e.g. Reference
Container Images). If folks
.
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 19 January 2015 at 11:59, Ben Finney ben+pyt...@benfinney.id.au wrote:
Nick Coghlan ncogh...@gmail.com writes:
If you have a build/install time only dependency that you want to
distribute, you *have* to separate it out into a separate component if
you don't want it to also be present
On 20 Jan 2015 09:11, Ben Finney ben+pyt...@benfinney.id.au wrote:
Tres Seaver tsea...@palladion.com writes:
On 01/19/2015 04:57 PM, Ben Finney wrote:
My current position would be: that's a bug in Setuptools, it should
not be applying entry points defined for package FOO when running
.
Then, in this case, you'd be able to run the Django 1.4 tests using
mezzanine[-comments] rather than a default install to avoid
attempting to install django-contrib-comments.
Filed as: https://github.com/pypa/interoperability-peps/issues/18
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On 19 January 2015 at 17:45, Ben Finney ben+pyt...@benfinney.id.au wrote:
Nick Coghlan ncogh...@gmail.com writes:
If you'd like to volunteer for the task of reverse engineering and
properly documenting how sdists work (with regression tests!), that
would be quite awesome. Not necessarily *fun
?
A local devpi instance is great for that kind of testing:
http://doc.devpi.net/latest/
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
and provide a useful error message if they're
missing).
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 Feb 2015 19:50, Reinout van Rees rein...@vanrees.org wrote:
Piotr Dobrogost schreef op 16-02-15 om 14:24:
From https://github.com/mitsuhiko/platter/ :
Platter is a utility for Python that simplifies deployments on Unix
servers.
It's a thin wrapper around pip, virtualenv and wheel
.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
, and have no low investment way to reduce the risk of it
happening again in the future), and a temporarily annoyed one (they
still got a nasty surprise, but they also learned about a useful
information feed highly relevant to their interests).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
(separating runtime, build, test and development
dependencies).
Other things are higher on the todo list right now than pushing that
forward, but we'll get there eventually.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 30 January 2015 at 04:27, Daniel Holth dho...@gmail.com wrote:
On Thu, Jan 29, 2015 at 8:37 AM, Nick Coghlan ncogh...@gmail.com wrote:
If we're on CPython 2.x and sysconfig.get_config_var('SOABI') returns
None, then we can calculate a synthetic SOABI tag as:
* the start of the SOABI tag
experience outside the
world of formal commercial compatibility certification programs.
Cheers,
Nick.
[1]
http://azure.microsoft.com/blog/2015/01/08/introducing-docker-in-microsoft-azure-marketplace/
[2] https://wiki.gnome.org/Projects/SandboxedApps
--
Nick Coghlan | ncogh...@gmail.com
creating native system packages (with varying degrees of
distro policy compliance). Scientific Python users publishers could
also be nudged in the direction of the conda/binstar.org ecosystem.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
significant PyPI and core packaging toolchain announcements
intermingled with the other existing announcements related to
conferences and various popular Python packages.
So a packaging toolchain specific changelog/announcement channel
likely makes sense.
Regards,
Nick.
--
Nick Coghlan
Armin Ronacher just published a new utility for creating prebuilt
virtualenv tarballs called platter: http://platter.pocoo.org/dev/
As he notes, it means you don't even need pip on your production systems.
From the looks of it, it would also be well suited as a foundation of the
venv in a native
account is optional
there). So this approach isn't necessarily about no social auth
allowed - it's about managing the risk of what happens if an external
identity provider goes away at some point in the future.
Cheers,
Nick.
[1] https://admin.fedoraproject.org/accounts/
--
Nick Coghlan | ncogh
.
Likewise, although in my case, Fedora had the Fedora Account System in
place long before I got involved in the project, and in my experience
it works well :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG
On 17 Mar 2015 02:33, Daniel Holth dho...@gmail.com wrote:
Problem: Users would like to be able to import stuff in setup.py. This
could be anything from a version fetcher to a replacement for
distutils itself. However, if setup.py is the only place to specify
these requirements there's a bit
On 17 March 2015 at 09:24, Nick Coghlan ncogh...@gmail.com wrote:
The main bottleneck where PEP 426 is concerned is me, and my current focus
is on Red Hat Project Atomic (e.g.
http://connect.redhat.com/zones/containers,
https://github.com/projectatomic/adb-atomic-developer-bundle) and the PSF
On 17 Mar 2015 04:33, Paul Moore p.f.mo...@gmail.com wrote:
On 16 March 2015 at 17:14, Donald Stufft don...@stufft.io wrote:
The bulk of the effort of pushing the standards, pip, and PyPI through
is done
by a handful of people, and of those handful I believe that the largest
share
is done
and the install side at the same time to really gain from them. One
possible way to go would be to have the initial pydist.json consumers
be redistribution tools like pyp2rpm, while pip continues to rely
solely on the old metadata files.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On 17 March 2015 at 19:52, Paul Moore p.f.mo...@gmail.com wrote:
On 16 March 2015 at 23:24, Nick Coghlan ncogh...@gmail.com wrote:
However, now that I know folks are keen to help with that side, I can
reprioritise getting the updates done so there's a better base to start
working from
On 17 Mar 2015 23:01, Daniel Holth dho...@gmail.com wrote:
So for me, metadata, while fine to have, is not the blocker for
generating wheels with some other build system. Having the other
build system is the blocker.
For me, it's not knowing what done looks like, even if a candidate
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
accordingly:
https://hg.python.org/peps/rev/8d7b218a99a8
Cheers,
Nick.
P.S. /me also bumps officially defining the provisional PEP
acceptance approach in PEP 1 even further down the todo list :)
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 20 Mar 2015 09:07, Ionel Cristian Mărieș cont...@ionelmc.ro wrote:
On Thu, Mar 19, 2015 at 10:38 PM, Nick Coghlan ncogh...@gmail.com wrote:
I believe setuptools can already do this (as setup-requirements.txt),
but it's a generated file that people tend not to check into source control
On 19 Mar 2015 23:33, Leonardo Rochael Almeida leoroch...@gmail.com
wrote:
On 18 March 2015 at 14:37, Daniel Holth dho...@gmail.com wrote:
[...]
The behavior we're aiming for would be:
installer run setup.py - installs things
python setup.py - does not install things
Besides that, I'd
TUF have been
higher priority since then.
So I agree it would be worthwhile to figure out an interim
improvement, but don't have a strong opinion on what that should look
like.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
business need. I'm pretty
happy with this piece I recently wrote for Red Hat as an example of
that kind of thing:
http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
be reviewed independently, but
later patches won't be merged until after earlier ones have been
submitted. (Rebasing support is also baked directly into the tool)
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
On 6 Mar 2015 22:10, Ben Finney ben+pyt...@benfinney.id.au wrote:
Nick Coghlan ncogh...@gmail.com writes:
CPython uses the Reitveld instance integrated with bugs.python.org,
and has the same problem as pip: incremental changes are a pain to
publish, review, and merge, so we review
On 7 Mar 2015 05:41, Piotr Dobrogost p...@2015.forums.dobrogost.net wrote:
Hi
As an external observer of pip project at github I see two men, namely
Xavier Fernandez (https://github.com/xavfernandez) and Marc Abramowitz
(https://github.com/msabramo) with many valuable contributions. I
think
On 7 Mar 2015 06:44, Ian Cordasco graffatcolmin...@gmail.com wrote:
On Fri, Mar 6, 2015 at 5:55 AM, Paul Moore p.f.mo...@gmail.com wrote:
The problem with discussing this sort of thing is that it's *very*
wide-ranging, and tends to produce huge rambling mega-threads[1] when
discussed in a
*other* environments.
Working on enabling that may also be a good opportunity to finally
hook the CPython Buildbot master up with the credentials it needs to
run ephemeral clients on Rackspace:
http://docs.buildbot.net/latest/manual/cfg-buildslaves-openstack.html
Cheers,
Nick.
--
Nick Coghlan
of potentially adopting your own
suggested Phabricator+GitHub approach wouldn't rank very high on pip's
process improvement list at this point.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist
consider that done (it may not go anywhere, but
there's no harm in asking).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo
On 8 Mar 2015 08:43, Piotr Dobrogost p...@2015.forums.dobrogost.net wrote:
On Fri, Mar 6, 2015 at 8:50 PM, piotr.dobrog...@autoera-serwer.home.pl
piotr.dobrog...@autoera-serwer.home.pl p...@2015.forums.dobrogost.net
wrote:
Hi
As an external observer of pip project at github I see two
On 25 Mar 2015 04:29, Paul Moore p.f.mo...@gmail.com wrote:
As a start, I'd suggest looking at writing some sort of independent
purge-package command that you could use when you hit problems (pip
install -U setuptools... weirdness happens, so purge-package
setuptools; pip install setuptools).
On 25 Mar 2015 07:35, Robert Collins robe...@robertcollins.net wrote:
This is a break-out thread from the centi-thread that spawned about
setup-requires.
d2to1 defined some metadata keys in setup.cfg,in particular 'name' and
'requires-dist'. Confusing 'requires-dist' contains the
On 25 Mar 2015 08:32, Nick Coghlan ncogh...@gmail.com wrote:
I like this idea, especially if the tool was made aware of the system
package manager date stores (at least for apt and rpm) and could hence emit
the appropriate dependency respecting system command for removing them in
those cases
On 31 Mar 2015 01:17, Xavier Fernandez xav.fernan...@gmail.com wrote:
Fair enough, I didn't think of compiled wheels :)
And having a clean way to run tests for the provided wheel is indeed an
other good point.
To elaborate on Donald's answer, one of our general requirements downstream
in
On 31 Mar 2015 04:11, Donald Stufft don...@stufft.io wrote:
On Mar 30, 2015, at 2:03 PM, Daniel Holth dho...@gmail.com wrote:
What else can we do to make the experience better for those who would
try to replace distutils?
Continue work on the interoperability standards that exist for
),
while development directories would continue to lack any of the
generated metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
On 1 Apr 2015 00:53, Paul Moore p.f.mo...@gmail.com wrote:
It's not quite that simple, I know. But until we work out how to do
something useful with a sdist that we can't do with a dev checkout,
it's hard to justify treating sdists specially.
I see it as more a matter of eventually migrating
On 28 Mar 2015 09:16, Donald Stufft don...@stufft.io wrote:
Use twine to upload
As Donald notes, twine can handle the upload, and devpi (unlike the public
PyPI) will happily host Linux wheel files.
The main trap to watch out for when using that approach in the current
system is that the wheel
://status.python.org/incidents/5w523lrn3587)
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 23 Feb 2015 10:05, Donald Stufft don...@stufft.io wrote:
On Feb 22, 2015, at 6:55 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 23 Feb 2015 09:50, Ben Finney ben+pyt...@benfinney.id.au wrote:
Richard Jones rich...@python.org writes:
Sorry, there's no facility at present
On 23 Feb 2015 09:50, Ben Finney ben+pyt...@benfinney.id.au wrote:
Richard Jones rich...@python.org writes:
Sorry, there's no facility at present for signing a file that's already
uploaded.
Thanks. I can now stop futilely trying to find it :-)
Twine lets you at least separate signing
On 24 Mar 2015 05:16, Chris Barker chris.bar...@noaa.gov wrote:
On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg drsali...@gmail.com
wrote:
Is this the general perspective on static linking of python module
dependencies? That if your systems are the same, you don't need to?
That's general
about what the PSF does in general (aside from
hosting pypi.python.org and the various other *.python.org services),
I also suggest checking out some of the other posts on the blog.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
practices)
Cheers,
Nick.
On Apr 2, 2015 7:02 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 2 April 2015 at 20:27, Thomas Güttler guettl...@thomas-guettler.de
wrote:
I hate the ORs and IFs in the python packaging world.
Can't it be done condition less?
Unfortunately, that's currently only
life a little interesting trying to get there :)
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 3 April 2015 at 08:09, Richard Jones rich...@python.org wrote:
Could the BoF be Friday instead please? Saturday is International Tabletop
Day, and there's a bunch of us will be celebrating that :)
Sure, Friday works for me, too.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
responsive pyserial community on
Stack Overflow: http://stackoverflow.com/questions/tagged/pyserial
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https
dependencies with conditional
ones, as well as apply environmental constraints to dependencies
included in an extra. I don't currently have any examples of mixing
and matching in the PEP, but it's *already* a monster document :(
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
On 13 May 2015 at 16:19, Ben Finney ben+pyt...@benfinney.id.au wrote:
Chris Barker chris.bar...@noaa.gov writes:
On Tue, Apr 14, 2015 at 8:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
The point where I draw the line is supporting *dynamic* linking
between modules -
I'm confused -- you
model.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
a this build dependency. That
can be hacked in, of course, but nicer not to have to.
By the time you've solved all these problems I believe you'll find you
have reinvented conda ;)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
release itself) was uploaded for the given package.
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 17 May 2015 06:19, Chris Barker chris.bar...@noaa.gov wrote:
indeed -- but it does have a bunch of python-specific featuresit was
built around the need to combine python with other systems.
That makes it an interesting alternative to pip on the package
*consumption* side for data
hosting. One possible option to
explore that minimises disruption for existing users might be to stop
offering it to *new* projects, while allowing existing projects to
continue uploading new versions of their documentation.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
On 18 May 2015 07:32, Chris Barker chris.bar...@noaa.gov wrote:
On Sun, May 17, 2015 at 12:05 AM, Nick Coghlan ncogh...@gmail.com wrote:
% pip install --upgrade pip
% pip install some_conda_package
This gets the respective role of the two tools reversed - it's like my
asking for pip
as an implementation detail, and then formalise it in the
next version of the wheel spec.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org
the capability I view as defining the
boundary between enabling an addon ecosystem for a programming
language runtime and providing a comprehensive software development
platform :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
understand.
So meta-installers like canopy could add their own extensions to their
generated wheel files, flag those extensions as required, and other
installers would correctly reject those wheels as unsupported.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
to the folks that are inclined to spend
our time reading RFCs and other specs :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
On 14 Apr 2015 04:04, Robert Collins robe...@robertcollins.net wrote:
Tl;dr: I woud like to change PEP-440 to remove the stigmata around dev
versions that come between pre-releases and releases.
The basic scenario here is developers and CD deployers building
versions from VCS of arbitrary
-versioning.rst
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 16 Apr 2015 03:08, Paul Moore p.f.mo...@gmail.com wrote:
Just to expand on another point in my mail - I'd like *anyone* to
provide an example of a genuine use case for something they think
should be a required installer extension. I'm not sure such a thing
actually exists...
The
On 16 Apr 2015 14:34, Paul Moore p.f.mo...@gmail.com wrote:
By the way. I just did a check through PEPs 426 and 459. Neither one
currently defines a postinstall script metadata item or extension,
which is interesting given that this discussion started from the
question of how postinstall
On 16 April 2015 at 17:42, Wes Turner wes.tur...@gmail.com wrote:
On Apr 14, 2015 7:15 PM, Nick Coghlan ncogh...@gmail.com wrote:
[...]
The perception that open source software is provided by magic internet
pixies that don't need to eat (or at the very least to be thanked for the
time
On 11 Apr 2015 12:22, Alexander Walters tritium-l...@sdamon.com wrote:
Is the package index really the best place to put this? This is a very
social-networking feature for the authoritative repository of just about
all the third party module, and it feels like either it could corrupt the
Guido mentioned in his PyCon keynote this morning that we don't currently
have a great way for package authors to ask for help from their user base.
It occurred to me that it could be useful to have a Help needed feature
on PyPI (after the Warehouse migration) where package maintainers could
.
Thoughts?
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
701 - 800 of 1528 matches
Mail list logo
