On 4 Jul 2013 18:52, "Vinay Sajip" wrote:
>
> Nick Coghlan gmail.com> writes:
>
> > * "install": the installation specifier for the dependency
> > * "extra": as per the current PEP (for conditional dependencies)
> > * "environment&
On 4 Jul 2013 21:35, "Donald Stufft" wrote:
>
>
> On Jul 4, 2013, at 7:00 AM, Nick Coghlan wrote:
>
>>
>> On 4 Jul 2013 18:52, "Vinay Sajip" wrote:
>> >
>> > Nick Coghlan gmail.com> writes:
>> >
>> > > *
On 4 Jul 2013 22:32, "Vinay Sajip" wrote:
>
> Donald Stufft 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 except arbitrarily addin
On 6 Jul 2013 04:08, "Jason R. Coombs" 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 means for pac
On 11 Jul 2013 04:56, "Brett Cannon" wrote:
>
>
>
>
> On Wed, Jul 10, 2013 at 12:11 PM, Paul Moore wrote:
>>
>> On 10 July 2013 15:28, Brett Cannon wrote:
So, at present, if I (as a 100% Python 3 user) want to install a
package, I type "pip install XXX". No version suffix. In the same
Users aren't stupid - the problem with the status quo is really that the
bootstrapping instructions are annoyingly complicated and genuinely
confusing, not that an explicit bootstrapping step is needed in the first
place.
Cheers,
Nick.
>
> Thanks everyone for your brilliant feed
heres to the Zen of Python, in particular:
* Explicit is better than implicit
* Simple is better than complex
* Readability counts
* Errors should never pass silently, unless explicitly silenced
* In the face of ambiguity, refuse the temptation to guess
* If the implementation is hard to explain, it&#x
On 12 July 2013 15:11, Nick Coghlan 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 virtuale
On 12 Jul 2013 18:36, "Vinay Sajip" wrote:
>
> Donald Stufft 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 and pip prior to usi
related to the packaging ecosystem). It achieves the aim of
allowing people to assume some version of pip will be present on Python
3.4+ installations (or readily available in the case of Linux), while
avoiding the problem of coupling pip updates to major Python version
updates.
Cheers,
Nick.
--
ylauncher over to the PyPA account on
BitBucket: https://bitbucket.org/pypa/
PEP 439 is the critical piece, since that's the one that takes the pressure
off getting the other components (including distlib and pkg_resources) into
the base installers.
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 13 July 2013 16:05, Donald Stufft wrote:
>
> On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
>
> I'm currently leaning towards offering both, as we're going to need a tool
> for bootstrapping source builds, but the simplest way to bootstrap pip for
> Windows a
On 13 Jul 2013 19:05, "Paul Moore" wrote:
>
> On 13 July 2013 06:31, Nick Coghlan wrote:
>>
>> * bundling a *full* copy of pip with the Python installers for Windows
and Mac OS X, but installing it to site-packages rather than to the
standard library directory.
huge, so we'll need time (or assistance!) to plan in and make changes
> like this, if they are needed...
>
Agreed, I think refocusing the discussion on "What do we need to do in
pip?" and "What do we need to do in CPython?" is a very
tility scripts.
The bundling PEP should also suggest to Linux packagers that pip be
considered an essential part of a fully functional Python installation.
Exactly how that is handled will be up to the distro packagers, but could
include noting pip as a recommended dependency for Python (Debian), or
r
upgrade older versions to the bundled version,
while leaving newer versions alone? Force installation of the bundled
version?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@
On 14 July 2013 16:19, Noah Kantrowitz wrote:
> On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
> > On 14 July 2013 12:46, Donald Stufft wrote:
> > Either the existing APIs are moved to a different name, or they get
> declared stable and pip switches to "internally
On 14 July 2013 16:34, Nick Coghlan wrote:
> On 14 July 2013 16:19, Noah Kantrowitz wrote:
>
>> On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
>> > On 14 July 2013 12:46, Donald Stufft wrote:
>> > Either the existing APIs are moved to a different name, or they
e
without adhering to standard naming conventions or providing an explicit
runtime warning to be unreasonable.
(and yes, if "pip" goes down the runtime warning path, we should probably
look into providing a runtime warning for at least the "test" namespace and
possibly even the
eeping old APIs around for a couple of years before
killing them off once the affected CPython branches go into security fix
only mode).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
at we wernt going to have to keep things
> around for really long times like python 4 ;)
>
Even most of the standard library isn't that conservative - it usually only
happens when we can't find a sensible place to hook up DeprecationWarning.
Cheers,
Nick.
--
Nick Coghlan |
On 14 Jul 2013 18:24, "Noah Kantrowitz" wrote:
>
>
> On Jul 14, 2013, at 12:35 AM, Nick Coghlan wrote:
>
> > On 14 July 2013 17:13, Donald Stufft wrote:
> > I think it would be reasonable for the pip maintainers to be asked to
declare a public API (even if that
1.4 was out the
door, but anyone on the PyPA list on BitBucket actually has full access to
accept pull requests, etc.
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 14 July 2013 23:01, Paul Moore wrote:
>
> On 14 July 2013 12:42, Nick Coghlan wrote:
>
>> This is the hole
>> https://python-packaging-user-guide.readthedocs.org/en/latest/ is
>> supposed to fill - once it's "ready" (i.e. things have stabilised
>
On 15 July 2013 00:28, Brett Cannon wrote:
>
>
>
> On Sun, Jul 14, 2013 at 2:13 AM, Nick Coghlan wrote:
>>
>> Based on the recent discussions, I now plan to reject the pip
>> bootstrapping-on-first-invocation approach described in PEP 439 in favour of
>&g
On 15 Jul 2013 05:44, "Paul Moore" wrote:
>
> On 14 July 2013 18:06, Donald Stufft wrote:
>>
>> Wouldn't a .py file make the command `pip.py`` and not ``pip`` ?
>
>
> Not if .py is a registered extension. What I can't remember is whether it
needs to be in PATHEXT (which it isn't by default). The
On 15 Jul 2013 07:45, "Paul Moore" wrote:
>
> On 14 July 2013 22:36, Marcus Smith wrote:
>>
>>
>>> That's 32600 projects, There are almost 200k distributions. And the
main table listing would be "Releases" or "Project Releases".
>>
>>
>> ok, got it. anything I do from here on will follow this.
On 15 July 2013 19:30, Ronald Oussoren wrote:
>
> On 13 Jul, 2013, at 7:31, Nick Coghlan wrote:
>>
>> 3. That means there are two main options available to us that I still
>> consider viable alternatives (the installer bundling idea was suggested in
>> one of the
On 15 July 2013 21:24, Paul Moore wrote:
>
> On 14 July 2013 07:13, Nick Coghlan wrote:
>>
>> * ensuring that pip is automatically available in virtual environments
>> created with pyvenv
>
>
> Is the proposal here for pyvenv to download pip or to install a local
nt to make scripts robust, a bit
> like -S and -E.
You'd think that, but then you'd look at getpath.c and run away (or
write something like PEP 432, as I did) :P
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 15 Jul 2013 01:10, "Paul Nasrat" wrote:
>
>
>
>
> On 14 July 2013 02:13, Nick Coghlan wrote:
>>
>> Based on the recent discussions, I now plan to reject the pip
bootstrapping-on-first-invocation approach described in PEP 439 in favour
of a new PEP that
er alone :-)
I, for one, am happy you opened it now rather than in a few months time!
If Paul Nasrat takes up the challenge of documenting all the practical
issues associated with bundling pip with the CPython binary installers
as a PEP, I expect he will need to work closely with you to capture
t
point wrappers if the wheel includes Python scripts in
{distribution}-{version}.data/scripts/ (see
http://www.python.org/dev/peps/pep-0427/#recommended-installer-features)
Now, there may be holes in that scheme, but it seemed solid enough
when I approved the PEP.
Cheers,
Nick.
--
Nick C
ncy should claim that name to define the default provider.
* noted that Debian packagers may want to map extras to Recommended or
Suggested packages
* noted some possible use cases for metadata extensions
* fixed and clarified various things in the reference copy of the JSON
schema (it could st
dows arcana right without some help.
Are we talking about the pip developers or python-dev, here? I think
Martin and Brian feel pretty lonely, too :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist
On 17 Jul 2013 05:34, "Donald Stufft" wrote:
>
>
> On Jul 16, 2013, at 1:54 PM, Vinay Sajip wrote:
>
> > Donald Stufft stufft.io> writes:
> >
> >> So to be clear, this means it's
> >>
> >> {
> >>"requires": [
> >>"foo",
> >>"bar"
> >>]
> >> }
> >>
> >> ?
> >>
> >> And it
On 17 Jul 2013 04:19, "Vinay Sajip" wrote:
>
>
>
> >If I were writing a firm proposal, I'd go for something like entry
points as metadata
>
> My extended metadata already covers this, though I use the name "exports"
(suggested by PJE) because you can share not just code but data, and "entry
points
On 17 Jul 2013 10:03, "Donald Stufft" wrote:
>
>
> On Jul 16, 2013, at 8:00 PM, Nick Coghlan wrote:
>
>>
>> On 17 Jul 2013 04:19, "Vinay Sajip" wrote:
>> >
>> >
>> >
>> > >If I were writing a firm proposal
On 17 Jul 2013 18:17, "holger krekel" wrote:
>
> On Wed, Jul 17, 2013 at 07:48 +, Vinay Sajip wrote:
> > holger krekel merlinux.eu> writes:
> >
> > > about existing schemes/efforts. I guess most Linux distros do it
already
> > > so if nothing comes up here PyPI-specific (what is the status o
n so many things at
once.
Cross compilation is one of the things the metabuild system would need
to take into account, which is one of the reasons it has been deferred
(see http://www.python.org/dev/peps/pep-0426/#metabuild-system - that
draft design *doesn't* handle cross compilation at all)
Che
ng supported platforms
5. The extras system extended across all the different kinds of
dependency (so if you don't want to build optional C accelerators, you
can express that clearly and skip all the associated dependencies)
Essentially, the standard tries to provide a better toolkit for
solving these
finally worked.
Thanks for the update! Glad you were able to get it working, and sorry
for the last few remnants of the setuptools/distribute fork process
causing you trouble :(
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 17 July 2013 22:40, Oscar Benjamin wrote:
> On 17 July 2013 13:17, Nick Coghlan wrote:
>> That said, the new metadata standard does deliberately include a few
>> pieces intended to make such things easier to define:
>>
>> 1. The extensions concept - using a struc
On 18 Jul 2013 01:46, "Daniel Holth" wrote:
>
> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon wrote:
> > I'm going to be pushing an update to one of my projects to PyPI this
week
> > and so I figured I could use this opportunity to help with patches to
the
> > User Guide's packaging tutorial.
>
On 18 Jul 2013 06:24, "Oscar Benjamin" wrote:
>
> On 17 July 2013 17:59, Brett Cannon wrote:
> >
> > But it also sounds like that project providing wheel distributions is
too
> > early to include in the User's Guide.
>
> There are already many guides showing how to use distutils/setuptools
> to d
On 18 Jul 2013 05:13, "Paul Moore" wrote:
>
> On 17 July 2013 19:55, Steve Dower wrote:
>>
>> > I'm afraid exe files as wrappers are probably the only viable option.
The basic
>> > reason is that the OS recognises exe files in all context, with no
special
>> > configuration needed. This is not tr
On 18 Jul 2013 08:18, "Brett Cannon" wrote:
>
>
>
>
> On Wed, Jul 17, 2013 at 6:12 PM, Nick Coghlan wrote:
>>
>>
>> On 18 Jul 2013 06:24, "Oscar Benjamin"
wrote:
>> >
>> > On 17 July 2013 17:59, Brett Cannon wr
On 18 Jul 2013 08:31, "Vinay Sajip" wrote:
>
> Nick Coghlan gmail.com> writes:
>
> > It's good that distil exists as a proof of concept, but the ship has
sailed
> on the default language level installer: it will be pip.
>
> I understand that it's
On 18 Jul 2013 09:37, "Vinay Sajip" wrote:
>
> Nick Coghlan gmail.com> writes:
>
> > Technically the decision *hasn't* been made - there is, as yet, no
> bundling PEP for me to consider for any installer, and I've decided not to
> accept Richard&
On 18 Jul 2013 09:37, "Vinay Sajip" wrote:
>
> Nick Coghlan gmail.com> writes:
>
> > Technically the decision *hasn't* been made - there is, as yet, no
> bundling PEP for me to consider for any installer, and I've decided not to
> accept Richard&
On 18 July 2013 10:33, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
> More importantly, it doesn't seem like the PEP process has been followed, as
> other proposed alternatives (I mean the approach of "python -m getpip", as
> well as my specific suggeste
r a PEP (since we already have way too many
other things in motion for people to sensibly keep track of), but this
certainly sounds promising - a post summarising your efforts to date
would be really helpful.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisb
taller is definitely something we
should consider for older versions (rather than updating the CPython
installer). Either way, Windows users are used to downloading and
running installers to get Python upgrades :)
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 18 July 2013 18:10, Paul Moore wrote:
> On 18 July 2013 08:57, Nick Coghlan wrote:
>>
>> Shipping an msi installer for pip (perhaps bundling with setuptools)
>> would also be an acceptable alternative.
>
>
> -1.
>
> I would suggest that this approach, if
d will likely never make it to the top, although it may
be more practical once pip vendors the bits it needs).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
ajip
>> To: Nick Coghlan
>> Cc:
>> Sent: Thursday, 18 July 2013, 8:41
>> Subject: Re: [Distutils] Q about best practices now (or near future)
>>
>>> From: Nick Coghlan
>>
>>
>>
>>> Then (help) write the missing PEP! PEP'
On 18 Jul 2013 21:48, "Oscar Benjamin" wrote:
>
> On 17 July 2013 22:43, Nick Coghlan wrote:
> >
> > On 18 Jul 2013 01:46, "Daniel Holth" wrote:
> >>
> >> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon
wrote:
> >> >
I actually now plan to make scripts and exports first class citizens in PEP
426, with pydist-scripts.json and pydist-exports.json as extracted summary
files (like the existing pydist-dependencies.json).
They're important enough to include directly.
Cheers,
Nick.
__
On 19 Jul 2013 08:42, "Nick Coghlan" wrote:
>
> I actually now plan to make scripts and exports first class citizens in
PEP 426, with pydist-scripts.json and pydist-exports.json as extracted
summary files (like the existing pydist-dependencies.json).
>
> They're
rnatives that aren't covered in PEP 439 extracted from the list
archives and turned into a PEP that compares them and suggests a
preferred solution.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
lure mode not yet identified - hence, my questions. I
> like to get into specifics :-)
I like the idea of switching to zc.buildout style entry points - it
makes it easier to get pip to a point where "no setuptools" means "can
only install from wheel files" rather than "can
f next year).
Posted now, though (I started working on it this morning and just hit
send before seeing this thread).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.or
On 19 July 2013 14:06, Nick Coghlan wrote:
> Already done or very close to done (Yay!):
>
> * improved PyPI SSL support
> * setuptools/distribute merger
> * easy_install SSL verification
> * setuptools support for additional hashes beyond md5
> * pip
On 19 July 2013 18:17, Paul Moore wrote:
> On 19 July 2013 05:06, Nick Coghlan wrote:
>>
>> * (hopefully) add support for indirect imports (see
>> http://mail.python.org/pipermail/import-sig/2013-July/000645.html for
>> the draft PEP - thanks Eric for taking this
t;we install this script" vs "we need a script wrapper generated
at install time for this"?
Not sure, I hadn't even the idea of letting people register arbitrary
"we install this script". Heck, I haven't even worked out what I want
the format to look like :)
I
On 19 July 2013 19:29, Paul Moore wrote:
> On 19 July 2013 05:23, Nick Coghlan wrote:
>>
>> On 19 July 2013 09:37, Vinay Sajip wrote:
>> >> I think the point is that people might be dependent on this
>> >> functionality and
>> >
>> >>
of two decades :P
Also, if we'd like to do cert verification in the bootstrap script,
keep in mind the fact that Python 2.6+ supports executable zip
archives, so long as they have a __main__.py file at the top level.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, A
On 19 July 2013 14:06, Nick Coghlan wrote:
> Independent activities & miscellaneous suggestions
>
> * maybe suggest "pip install distlib" over pip gaining its own
> programmatic API?
> * PEP 8 cleanup (including clarification of what constitutes an
> int
On 19 July 2013 14:06, Nick Coghlan wrote:
> We have a lot of initiatives going every which way at the moment, so I
> figured it would be a good idea to get a common perception of what we
> consider to be the important near term goals and a realistic timeline
> for improving t
particular Python installation remains under
the control of the PEP 376 installers (including pip).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
2.0 standard in
PEP 426 (ever since Daniel realised that wheels could work just as a
well with setuptools compatible metadata as they could with a new
metadata standard).
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 20 July 2013 01:47, PJ Eby wrote:
> On Fri, Jul 19, 2013 at 9:10 AM, Nick Coghlan wrote:
>> Right, I think the reasonable near term solutions are for pip to either:
>>
>> 1. generate zc.buildout style wrappers with absolute paths to avoid
>> the implied runtime dep
ing able to *explain* the new
metadata easily. Previously, merging the requirements wasn't
especially practical, due to the requires/may_require split. Now,
though, it's possible to merge them and have the keys match exactly
with the names used in ":run:", etc.
However, I
that's more appropriately
handled on the consumer side of things than it is on the installer
side.
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 July 2013 17:40, Paul Moore wrote:
> On 20 July 2013 04:27, Nick Coghlan wrote:
>>
>> It doesn't help that the
>> Microsoft provided UI for configuring environment variables hasn't
>> seen any serious improvements in the better part of two decades :P
On 21 Jul 2013 04:43, "Daniel Holth" wrote:
>
> On Sat, Jul 20, 2013 at 2:10 AM, Nick Coghlan wrote:
> > On 20 July 2013 01:47, PJ Eby wrote:
> >> On Fri, Jul 19, 2013 at 9:10 AM, Nick Coghlan
wrote:
> >>> Right, I think the reasonable near term sol
On 21 July 2013 11:53, PJ Eby wrote:
> On Sat, Jul 20, 2013 at 8:08 PM, Nick Coghlan wrote:
>> I see it as more useful for making an executable optional by defining a
>> "cli" extra. If your project just gets installed as a dependency, no wrapper
>> would get ge
On 22 Jul 2013 01:46, "PJ Eby" wrote:
>
> On Sat, Jul 20, 2013 at 10:54 PM, Nick Coghlan wrote:
> > Extras should just be a way to ask "are these optional dependencies
present
> > on this system?", without needing to worry about how they got there.
>
>
On 22 Jul 2013 13:26, "PJ Eby" wrote:
>
> On Sun, Jul 21, 2013 at 6:44 PM, Nick Coghlan wrote:
> >
> > On 22 Jul 2013 01:46, "PJ Eby" wrote:
> >>
> >> Now that I'm thinking about it some more, one of the motivating use
> >> c
On 22 Jul 2013 19:12, "Vinay Sajip" wrote:
>
> Nick Coghlan gmail.com> writes:
>
> > On 22 Jul 2013 01:46, "PJ Eby" telecommunity.com> wrote:
>
> > > To put it another way, it's not "exported only if extra is available",
On 22 Jul 2013 21:29, "Paul Moore" wrote:
>
> On 22 July 2013 12:22, Nick Coghlan wrote:
>>
>> since extras aren't really a thing in their own right (they're just a
shorthand for referring to an additional set of dependencies)
>
>
> I'm still
On 23 Jul 2013 05:53, "Carl Meyer" wrote:
>
> On 07/22/2013 06:31 AM, Daniel Holth wrote:
> > Yes, extras are *only* a way to create aliases for a set of
> > dependencies. They are not recorded as installed. It should make no
> > difference whether you install ipython[notebook], look up the
> > de
On 25 Jul 2013 03:30, "Donald Stufft" wrote:
>
>
> On Jul 24, 2013, at 1:10 PM, Carl Meyer wrote:
>
> > On 07/21/2013 01:38 PM, Piotr Dobrogost wrote:
> >> Does pip support installation of the latest _stable_ version of package
> >> (for all versions which adhere to PEP386)?
> >> Related - "Do no
On 26 Jul 2013 10:45, "Barry Warsaw" wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Jul 25, 2013, at 03:37 PM, Philip Jenvey wrote:
>
> >What's the value of sys.executable in the brave new world of
distributions
> >that follow PEP 394?
>
> One use case is locating other script
private source control repo.
Published software is actually the vanishingly small tip of a very
large iceberg, especially for languages like Python that handle
scripting use cases fairly well and are thus popular for personal
automation tasks amongst developers and system administrators.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
anishingly small subset of
humanity - anybody conservative enough to be running a version of RHEL
that old is going to have *very* strict rules about how software gets
onto their production servers and are also likely to be using
something far more recent to talk to the outside world.
C
give it a bit to make sure no one does
> have an issue with the move.
+1, this sounds like a good way forward for the existing PyPI interfaces.
We can do something better once the focus shifts from "make the status
quo not broken" to making the next generation interfaces a reali
On 29 July 2013 19:38, holger krekel wrote:
> Hi Nick, Donald, all,
>
> On Sun, Jul 28, 2013 at 22:23 +1000, Nick Coghlan wrote:
>> On 28 July 2013 20:55, Donald Stufft wrote:
>> > Ok so given that:
>> >
>> > - There's a readably available sol
On 30 Jul 2013 05:15, "Donald Stufft" wrote:
>
>
> On Jul 29, 2013, at 2:57 PM, zooko wrote:
>
>> I'd like to push back on the other risk, that someone might figure out
how to
>> make MD5 second-pre-images. I don't think this is a risk that we need to
>> urgently address, and I've written a short
volunteering to do the
work needed to improve the Python community's software distribution
infrastructure.
That's the plan, anyway, even if it isn't always all that effective in
practice :(
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
On 30 Jul 2013 21:41, "Antoine Pitrou" wrote:
>
> Donald Stufft stufft.io> writes:
> > > You don't happen to be a random security professional, you are
actually part
> > > of that upstream project and you have access to non-public (possibly
> > > confidential)
> > > data about its infrastructure,
On 31 Jul 2013 08:49, "Vinay Sajip" wrote:
>
> I'm looking at PEP 426 specifications for installation hooks and wondering
> whether we need to tighten up the specification a little.
>
> My concern stems from the fact that hook code needs to be installed along
> with other code - at least, the code
prime-time yet.
I wanted to get this part up so anyone tinkering with wrapper scripts
had at least a preliminary scheme to work from, but as per the note on
time frames, I don't consider the details of PEP 426 to be an urgent
topic for further discussion unless/until it directly impacts next
ge
On 3 Aug 2013 06:01, "PJ Eby" wrote:
>
> On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan wrote:
> > I pushed a version of PEP 426 with an initial sketch of an entry
> > points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02
> >
> > To give i
On 3 August 2013 13:03, Nick Coghlan wrote:
> How about we go with:
>
> Valid dotted names for:
> - modules
> - namespaces
> - module & name portions of export specifiers
> - export group names
> - extension names
>
> Valid distribution names for:
> - scri
On 4 August 2013 05:14, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
>> Just pushed these changes.
>
> One more problem: the updated pydist-schema.json is not a valid schema file
> (it's not valid JSON either- I think there are trailing commas and a
> m
g protocol (and perhaps even mention
that the current preferred mirroring tool is bandersnatch rather than
pep381client), but the CDN is considered to replace the public mirror
network and those DNS names will all be retired.
Cheers,
Nick.
--
Nick Coghl
On 4 August 2013 19:18, Donald Stufft wrote:
>
> On Aug 4, 2013, at 5:13 AM, Nick Coghlan wrote:
>
>> On 4 August 2013 18:48, Donald Stufft wrote:
>>> 5 days ago my branch to remove mirroring support from pip was merged into
>>> pip's develop bran
I filed the request on the metatracker:
http://psf.upfronthosting.co.za/roundup/meta/issue522
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
priate here.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
701 - 800 of 1620 matches
Mail list logo
