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
r the underlying security
model is almost certainly going to break 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
thos
ill be
the last time where something that initially seemed like a good idea
doesn't seem so promising once it's exposed to a broader audience.
That's exactly the kind of problem PEP 411 was designed to deal with
for the standard library, so extending it to the PyPA ecosystem makes
a lot o
ge model Maurits 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, e
rmats anyway, as
normalisation for publication is only a SHOULD, rather than a MUST.
Switching the preferred format 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-sig
On 18 Dec 2014 20:30, "Olivier Grisel" 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. I'll also include t
On 19 Dec 2014 03:50, "Marcos Klein" 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 leads me to
>> (perhaps every few months) sign metadata with an offline key. PEP 480 also
>> proposes an easy-to-use key management solution for developers, how to
>> interface with a potential build farm on PyPI infrastructure, and discusses
>> the security benefits of end-to-en
On 23 Dec 2014 19:02, "Donald Stufft" wrote:
>
>
>> On Dec 23, 2014, at 1:03 AM, Marcus Smith 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, 2014 at 9:57 PM, Ma
On 24 Dec 2014 05:27, "Marcus Smith" 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 directly
On 25 Dec 2014 03:25, "Marcus Smith" 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, and, un
On 25 Dec 2014 06:51, "Marcus Smith" 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 virtualenv.
>
>
On 28 Dec 2014 17:12, "Donald Stufft" wrote:
>
>
>> On Dec 27, 2014, at 9:26 PM, Donald Stufft wrote:
>>
>>
>>> On Dec 27, 2014, at 9:10 PM, Marcus Smith wrote:
>>>
In gives me a minor bit of pause. However any alternative that I can
come up
with bothers me more, especially since I don
the new GitHub repo)
* I'll write a new PEP proposing some changes to PEP 1 based on the things
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 st
On 29 December 2014 at 15:01, Nick Coghlan wrote:
> Next steps:
>
> * I'll update the currently published version of PEP 440 to include a note
> regarding its provisional status
>
I just pushed this as https://hg.python.org/peps/rev/a532493ba99c
Cheers,
Nick.
--
Nick
On 29 December 2014 at 17:12, Marcus Smith 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, Aus
On 30 December 2014 at 05:09, Chris Jerdonek
wrote:
> On Mon, Dec 29, 2014 at 12:01 AM, Nick Coghlan wrote:
> > * for those cases (like date-based versions) where excluding releases
> with
> > an additional numeric suffix is the right thing to do, an explicit prefix
> >
On 23 December 2014 at 04:15, Vladimir Diaz
wrote:
> On Mon, Dec 22, 2014 at 11:30 AM, Nick Coghlan 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 in PEP
>> 480,
to look for assistance
through Debian and/or Ubuntu specific channels - while we do see folks like
Matthias Klose and Barry Warsaw here on distutils-sig occasionally, I don't
believe there's anyone specifically monitoring this list for questions
about the distro level integration uti
es to the tools, so I don't mind 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
d of upload compromise based attack is also
out of scope for PEP 458 - that's now entirely about ensuring that the bits
delivered to end users are the same bits PyPI published. Making sure that
the bits *PyPI* publishes are the same ones that the *developer* published
is the domain of PEP 48
On 31 Dec 2014 10:43, "Chris Barker" wrote:
>
> But the core problem here is that the scipy folks have been going to
conda and enthought to solve their pacakgeing problems, and the web folks
have been doing pip, and maybe buildout -- so you get a bit of mess when
you mix them.
The problem always
design concept that will
make or break PEP 480 - the security model of TUF looks great to me, what
gives me pause is concern over the usability and maintainability of signed
uploads for "developers in a hurry".
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisb
quot;common
knowledge" in these areas, and the TUF folks leave me in the dust :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
edu/soups/2010/proceedings/a11_Walsh.pdf. While the
paper is specifically written in the context of home PC security, I think
that's good advice in general: adjusting software systems to accommodate
the reality of human behaviour is usually going to be far more effective
than attempting to teach
On 2 January 2015 at 16:13, Donald Stufft wrote:
>
> On Jan 2, 2015, at 12:57 AM, Nick Coghlan 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 users in
On 2 January 2015 at 16:38, Donald Stufft wrote:
>
> On Jan 2, 2015, at 1:33 AM, Nick Coghlan 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 t
volved in creating a robust PEP than you might wish ;)
> Either way though, I suggest focus on PEP 458 (with an eye towards not
> making
> any decisions which will require changes on the client side to implement
> PEP
> 480).
>
Yep. I'll make one more post to try to cl
which don’t scale at TLS scale might scale at PyPI scale.
>
It's worth noting that my validation server idea is still very much a
CA-style model - it's just that instead of registering developer keys with
PyPI (as in PEP 480), we'd be registering the trust roots of metadata
validat
to ensure there's a clear
explanation of the practical consequences for folks that we'd otherwise
lose in the cryptographic weeds.
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 wrote:
>
> On Jan 2, 2015, at 10:51 AM, Nick Coghlan 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, and the p
lity-peps repo with the rest of them, and add Vladimir et
al as developers on that repo (or just to the general PyPA 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
ing to have a namespace package at the end of it :)
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 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
> ve
vely
install pieces of the package itself (the affected subcomponents are
instead expected to do runtime checks to see if the optional
dependencies are present 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 19 January 2015 at 14:11, Ben Finney wrote:
> So should I expect that, if a module is not specified in the ‘packages’
> parameter nor the ‘py_modules’ parameter, it will not be installed?
It won't be installed, but I suspect it also won't end up in the sdist either.
Cheers,
On 19 January 2015 at 11:59, Ben Finney wrote:
> Nick Coghlan 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 at runtime.
On 19 January 2015 at 17:45, Ben Finney wrote:
> Nick Coghlan 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* fr
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/listinfo/distutils-sig
On 20 Jan 2015 09:11, "Ben Finney" wrote:
>
> Tres Seaver 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 the
> > > setup for some other packag
ould still be
installed by default, but you'd have an easy way to turn them off if
you didn't want them.
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-
unexpected change,
being able to answer "How can I avoid being surprised like this
again?" with "Subscribe to this tightly focused RSS feed" can make the
difference between a genuinely unhappy user (they got a nasty
surprise, and have no low investment way to reduce the risk of it
ontents of the python-announce list,
and I suspect even that would be a bit high volume if we had
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
nyway :)
Thanks for tackling this 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
character will be 'u' if sys.maxunicode == 0x10
We're not going to add a new kind of ABI variation to Python 2 at this
stage of its lifecycle, so that calculation should remain valid for as
long as Python 2 remains in use.
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 30 January 2015 at 04:27, Daniel Holth wrote:
> On Thu, Jan 29, 2015 at 8:37 AM, Nick Coghlan 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
w tell
> how I am wrong about that ;) .
You're right, which is why PEP 426 has a more fine-grained dependency
specification model (separating runtime, build, test and development
dependencies).
Other things are higher on the todo list right now than pushing that
forwar
nments, including the Google &
Red Hat backed Kubernetes container orchestration framework and
OpenStack's Project Solum. In my day job, this is also the direction
we're taking Red Hat's internal infrastructure since it systematically
solves a variety of problems for us (like h
works well for a wide range
of users, a much wider range than the "do-your-own-integration"
adventure that has been the traditional Linux experience outside the
world of formal commercial compatibility certification programs.
Cheers,
Nick.
[1]
http://azure.microsoft.com/blog/2015/01/08/i
, but also the technique of
"bundle a /opt virtualenv in a platform binary package" as well as
actually creating native system packages (with varying degrees of
distro policy compliance). Scientific Python users & publishers could
also be nudged in the direction of th
is problem as well,
> although it's still vaporware right now.
>
> http://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
_
>
> After all, there's nothing special 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.ione
On 3 Feb 2015 19:10, "Paul Moore" wrote:
>
> On 1 February 2015 at 03:54, Nick Coghlan 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
,
although I think the "native" password controlled 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.
C
t you to relevant ML/IRC conversations and software
> if it helps in any way.
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 |
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 nat
On 18 Feb 2015 19:50, "Reinout van Rees" 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 and ai
On 23 Feb 2015 09:50, "Ben Finney" wrote:
>
> Richard Jones 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 from the build step, though:
https://
On 23 Feb 2015 10:05, "Donald Stufft" wrote:
>
>
>> On Feb 22, 2015, at 6:55 PM, Nick Coghlan wrote:
>>
>>
>> On 23 Feb 2015 09:50, "Ben Finney" wrote:
>> >
>> > Richard Jones writes:
>> >
>> > >
been
affected by the Rackspace rolling restarts earlier
(https://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
u're already helped them cross a
lingering item off their generally voluminous todo lists.
Regards,
Nick.
P.S. The other useful thing to do is to better educate folks on how to
make the case for spending work time on upstream projects and key
dependencies, *without* a specific
eaker-project.org/#/c/4025 is an example of a fairly
deep patch stack, where each patch can 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..
On 6 Mar 2015 22:10, "Ben Finney" wrote:
>
> Nick Coghlan 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
On 7 Mar 2015 05:41, "Piotr Dobrogost" 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 it would be beneficia
On 7 Mar 2015 06:44, "Ian Cordasco" wrote:
> On Fri, Mar 6, 2015 at 5:55 AM, Paul Moore 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 public list. I'm not advocating an
t broken any *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
iager" level of
permissions, so even the idea 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
___
der 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/distutils-sig
On 8 Mar 2015 08:43, "Piotr Dobrogost" wrote:
>
> On Fri, Mar 6, 2015 at 8:50 PM, piotr.dobrog...@autoera-serwer.home.pl
> piotr.dobrog...@autoera-serwer.home.pl
> wrote:
> > Hi
> >
> > As an external observer of pip project at github I see two men, namely
> > Xavier Fernandez (https://github.com
and Warehouse & 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
On 17 Mar 2015 02:33, "Daniel Holth" 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 of a chick
On 17 Mar 2015 04:33, "Paul Moore" wrote:
>
> On 16 March 2015 at 17:14, Donald Stufft 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 by myself. That's not to t
On 17 March 2015 at 09:24, Nick Coghlan 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) an
On 17 March 2015 at 19:52, Paul Moore wrote:
> On 16 March 2015 at 23:24, Nick Coghlan 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.
>
>
ear view
as to how the adoption of the *new* capabilities will work, as we get
the old chicken-and-egg problem of needing to update the build side
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 redistri
On 17 Mar 2015 23:01, "Daniel Holth" 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
alternative buil
reed, and I've updated the PEP 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 C
vely simple and straightforward problem compared to
figuring out how to build the backbone infrastructure that lets open
source developers learn one set of software distribution tooling
themselves, while still being to relatively easily feed into all of
the other downstream systems :)
Cheers,
N
On 19 Mar 2015 23:33, "Leonardo Rochael Almeida"
wrote:
>
>
> On 18 March 2015 at 14:37, Daniel Holth 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 add that w
On 20 Mar 2015 09:07, "Ionel Cristian Mărieș" wrote:
>
>
> On Thu, Mar 19, 2015 at 10:38 PM, Nick Coghlan wrote:
>>
>> I believe setuptools can already do this (as "setup-requirements.txt"),
but it's a generated file that people tend not to check in
On 24 Mar 2015 05:16, "Chris Barker" wrote:
>
> On Mon, Mar 23, 2015 at 11:45 AM, Dan Stromberg
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 -- nothing specific to pytho
On 25 Mar 2015 04:29, "Paul Moore" 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). If all the s
On 25 Mar 2015 08:32, "Nick Coghlan" 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 case
On 25 Mar 2015 07:35, "Robert Collins" 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
> 'install_requires' one migh
On 28 Mar 2015 09:16, "Donald Stufft" 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 filenames won
On 31 Mar 2015 04:11, "Donald Stufft" wrote:
>
>
> > On Mar 30, 2015, at 2:03 PM, Daniel Holth 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 that very
> purpose.
On 31 Mar 2015 01:17, "Xavier Fernandez" 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 distro land is the abili
alling (or building wheels from) the two things
> differently.
Yep, the current PEP 426 draft suggests that sdists should grow a
"dist-info" directory (akin to wheel files and installed packages),
while development directories would continue to lack any of the
generated metadata.
Cheers
On 1 Apr 2015 00:53, "Paul Moore" 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 to a "devdir -
message on.
If you're curious 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...@
nce distutils was first
released just makes 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
r own development practices)
Cheers,
Nick.
>
> On Apr 2, 2015 7:02 AM, "Nick Coghlan" wrote:
>>
>> On 2 April 2015 at 20:27, Thomas Güttler
wrote:
>> > I hate the "ORs" and "IFs" in the python packaging world.
>> >
>&
On 3 Apr 2015 07:03, "Richard Jones" wrote:
>
> I can't speak for any plans others active in the PyPA might have, but
I'll be using the sprint time to work on Warehouse and hopefully help
others work on it also.
>
> I'm almost certain that my hallway track time will involve many
packaging-related
On 3 April 2015 at 08:09, Richard Jones 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 |
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
reg
On 11 Apr 2015 12:22, "Alexander Walters" 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
'sanctity' of the reposito
looks
like, then it will be part of the role of packaging.python.org to
provide the "just the facts" introduction that lowers the barriers to
entry, leaving the raw spec to the folks that are inclined to spend
our time reading RFCs and other specs :)
Cheers,
Nick.
--
Nick Coghlan
da). The point where I draw the line is supporting *dynamic*
linking between modules - that's the capability I view as defining the
boundary between "enabling an addon ecosystem for a programming
language runtime" and "providing a comprehensive
rwise, installers are free to
ignore extensions they don't 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.
--
On 14 Apr 2015 09:28, "Daniel Holth" wrote:
>
> That's exactly what I would like to do. Then
> distribution-1.0.data/sysconfdir/file in a wheel would install into
> /etc/file in the default scheme, but would probably really wind up in
> $VIRTUAL_ENV/etc/... for most of us web developers.
>
> IIRC
101 - 200 of 1620 matches
Mail list logo
