ully MvL or someone can do the same with the Windows installer.
I'm not sure what needs done outside of the up front work, do I just propose
changes to PEP 101? Do I make a whole new PEP? Is there more than
just updating PEP 101?
>
> --
> Ned Deily,
> n...@acm.org
>
> ___
need to be done inside the installers (mostly running the
command).
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
he separate pip package when a user executes ``pip`` without
+it being installed. Systems that choose this option should ensure that
+the ``pyvenv`` command still installs pip into the virtual environment
+by default.
* Do not remove the bundled copy of pip.
---------
Do
y for new users, so the ideal method is to ensure it's always installed
but it'd be totally OK to do what Nick suggested as that still at leasts lets
pypi
packages to simply document installing as ``pip install `` and if it's
not
installed by default on Debian they'll get a
On Sep 19, 2013, at 9:50 AM, Antoine Pitrou wrote:
> Le Thu, 19 Sep 2013 09:27:24 -0400,
> Donald Stufft a écrit :
>> We've updated PEP453 based on some of the early feedback we've gotten
>> from -dev and Martin.
>>
>> Major changes:
>>
>&g
On Sep 19, 2013, at 9:43 AM, Paul Moore wrote:
> On 19 September 2013 14:27, Donald Stufft wrote:
>> Major changes:
>>
>> * Removal of the option to fetch pip from PyPI in order not to modify the
>> trust model of the Python installers
>> * Consequently re
On Sep 19, 2013, at 9:36 AM, Paul Tagliamonte wrote:
> On Thu, Sep 19, 2013 at 09:27:24AM -0400, Donald Stufft wrote:
>> Rationale
>> =
>>
>> Currently, on systems without a platform package manager and repository,
>> installing a third-party Python
On Sep 19, 2013, at 9:27 AM, Donald Stufft wrote:
> We've updated PEP453 based on some of the early feedback we've gotten from
> -dev and Martin.
>
> Major changes:
>
> * Removal of the option to fetch pip from PyPI in order not to modify the
> trust
n.org/dev/peps/pep-0439/
References
==
.. [#ubuntu] `Ubuntu <http://www.ubuntu.com/>`
.. [#debian] `Debian <http://www.debian.org>`
.. [#fedora] `Fedora <https://fedoraproject.org/>`
.. [#homebrew] `Homebrew <http://brew.sh/>`
.. [#conda] `Conda <http://www.conti
ng list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
s
On Sep 10, 2013, at 11:08 AM, Guido van Rossum wrote:
> Why do several posts in this thread have an Unsubscribe link that tries to
> unsubscribe me from the list? (I saw one by Glen, and another one by Donald
> Stufft.)
>
> (Come to think of it, what's the point of hav
On Sep 6, 2013, at 3:34 PM, "R. David Murray" wrote:
> On Fri, 06 Sep 2013 15:17:12 -0400, Donald Stufft wrote:
>> On Sep 6, 2013, at 3:11 PM, "R. David Murray" wrote:
>>
>>> IMO, single signon is overrated. Especially if one prefers not to
__
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A92
the news a lot lately :)
If I recall Persona doesn't leak this data like OpenID does, but perhaps Dan
can speak to that better than I can.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed
mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCF
ized, and free systems like OpenID and Persona.
>
> -Barry
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
--
On Sep 5, 2013, at 2:43 PM, Oleg Broytman wrote:
> On Thu, Sep 05, 2013 at 02:35:16PM -0400, Donald Stufft
> wrote:
>> Persona is the logical successor to OpenID.
>
> OpenID lived a short life and died a quiet death. I'm afraid Persona
> wouldn't live even t
On Sep 5, 2013, at 2:25 PM, Oleg Broytman wrote:
> On Thu, Sep 05, 2013 at 02:16:29PM -0400, Donald Stufft
> wrote:
>>
>> On Sep 5, 2013, at 2:12 PM, Oleg Broytman wrote:
>>> I used to use myOpenID and became my own provider using poit[1].
>>> These d
leg Broytmanhttp://phdru.name/p...@phdru.name
> Programmers don't die, they just GOSUB without RETURN.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
>
thoroughly with the
>> new version before upgrading.
>>
>> Petri
> ___________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
&g
On Jun 16, 2013, at 1:52 AM, Ben Finney wrote:
> Donald Stufft writes:
>
>> On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:
>>> Is there anything I can do to keep the ‘enum’ package online for
>>> continuity but make it clear, to automated tools, that this is
&g
On Jun 15, 2013, at 10:45 PM, Ben Finney wrote:
> Ethan Furman writes:
>
>> So I have the stdlb 3.4 Enum backported for both earlier 3.x and back
>> to 2.4 in the 2.x series.
>>
>> I would like to put this on PyPI, but the `enum` name is already
>> taken.
>
> I have for a long time approved
onald%40stufft.io
I claimed backport.enum, but you're welcome to the name. I was going to try and
backport this PEP under that name anyways.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signe
I never want to iterate, but I love slice syntax and indexing. Don't think you
can have that w/o being able to loop over it can you? Maybe I'm just thinking
slow since I just woke up.
On Jun 15, 2013, at 8:53 AM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/
mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
This is probably more appropriate for distutils-sig, but does it happen every
time? or did it just happen once
On Jun 3, 2013, at 6:01 PM, Paul Moore wrote:
>
> On 3 June 2013 22:46, Donald Stufft wrote:
>> Also, we should consider the issue for application users. Suppose I'm using
>> a Python application that downloads something from the web. I upgrade to
>> 3.4, and
On Jun 3, 2013, at 5:51 PM, Antoine Pitrou wrote:
> On Mon, 3 Jun 2013 17:47:31 -0400
> Donald Stufft wrote:
>>
>> On Jun 3, 2013, at 5:41 PM, Antoine Pitrou wrote:
>>
>>> On Mon, 3 Jun 2013 22:31:40 +0100
>>> Paul Moore wrote:
>>>>
have a *very* good story for (legitimate) sites which do cease to work.
>
> Paul.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailm
t;
> Regards
>
> Antoine.
>
>
> ___________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/donald%40stuff
thon-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
What about OSX?
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5
On Jun 3, 2013, at 1:07 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 02:17 PM, Donald Stufft wrote:
>
>> I'd actually prefer for Linux to not use the bundled certs when installed
>> from a package manager because it should use the system certs, but people
>> can&
t,
they
won't need to bundle their own certs and ubuntu/debian can just modify the one
location instead of needing to modify it for every package that does it.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.
On Jun 3, 2013, at 12:52 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 03:12 AM, Donald Stufft wrote:
>
>> That's fine with me too. My only reason for wanting to use the system certs
>> first is so if someone has modified their system certs (say to include a
>>
On Jun 3, 2013, at 12:36 PM, Barry Warsaw wrote:
> On Jun 03, 2013, at 01:20 AM, Donald Stufft wrote:
>
>> So I would like to propose that CPython adopt the Mozilla SSL certificate
>> list and include it in core, and switch over the API's so that they verify
>> H
On Jun 3, 2013, at 12:52 PM, Ethan Furman wrote:
> On 06/03/2013 09:43 AM, Donald Stufft wrote:
>> On Jun 3, 2013, at 5:51 AM, Antoine Pitrou wrote:
>>>
>>> The problem with a "slightly outdated" CA store is that it can be a
>>> security risk.
>
/donald%40stufft.io
Tracking the Mozilla store isn't difficult. New additions can be ignored for
currently released Pythons so we'd just need to watch them for blacklisting
certs and roll that into a security update.
-
Donald Stufft
PGP: 0x6E3CBCE93372DC
On Jun 3, 2013, at 1:58 AM, Benjamin Peterson wrote:
> 2013/6/2 Donald Stufft :
>> As of right now, as far as I can tell, Python does not validate HTTPS
>> certificates by default. As far as I can tell this is because there is no
>> guaranteed certificates available.
>
m
certificate store if possible, and if that doesn't work falling back to the
bundled certificates. That way the various Linux distros can easily have their
copies of Python depend soley on their built in certs, but Windows, OSX, Source
compiles etc will all still have a fallback value.
> Steven
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372D
___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/donald%40stufft.io
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Barry Warsaw wrote:
> On Mar 05, 2013, at 02:11 AM, Donald Stufft wrote:
>
>> Doesn't setuptools/distribute already have a setup.py test command?
>> That seems like the easiest way forward?
>
> Yes, and in theory it c
On Tuesday, March 5, 2013 at 2:02 AM, Lennart Regebro wrote:
> On Tue, Mar 5, 2013 at 1:41 AM, Robert Collins
> mailto:robe...@robertcollins.net)> wrote:
> > So that is interesting, but its not sufficient to meet the automation
> > need Barry is calling out, unless all test suites can be run by
> >
A big +1 from me for cffi in the stdlib it's a great library.
I just recently started using it to make bindings to a C library. I
looked at the ctypes library, but haven't actually used it, because
the docs confused me but with cffi I was able to get somewhere just
by a liberal use of copy/paste f
On Wednesday, February 20, 2013 at 6:22 PM, Antoine Pitrou wrote:
> On Wed, 20 Feb 2013 18:21:22 -0500
> Donald Stufft mailto:donald.stu...@gmail.com)>
> wrote:
> > On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
> > > > It's not a distr
On Wednesday, February 20, 2013 at 6:23 PM, Christian Heimes wrote:
> We can add a function to the XML package tree that enables all restrictions:
>
> * limit expansion depths of nested entities
> * limit total amount of expanded chars
> * disable external entity expansion
> * optionally force exp
On Wednesday, February 20, 2013 at 6:08 PM, Antoine Pitrou wrote:
> > It's not a distributed DoS issue, it's a severe DoS vulnerabilities. A
> > single 1 kB XML document can kill virtually any machine, even servers
> > with more than hundred GB RAM.
> >
>
>
> Assuming an attacker can inject arbi
On Wednesday, February 20, 2013 at 2:48 AM, Chris Jerdonek wrote:
> On Tue, Feb 19, 2013 at 3:16 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote:
> > Sorry, Chris must have meant http://hg.python.org/distlib/ . I was
> > struggling to imagine a world where that is more visible than something on
On Tuesday, February 19, 2013 at 6:16 PM, Daniel Holth wrote:
> Sorry, Chris must have meant http://hg.python.org/distlib/ . I was struggling
> to imagine a world where that is more visible than something on bitbucket.
> Half the comments have been about putting something in stdlib right away,
>
On Tuesday, February 19, 2013 at 3:25 PM, Paul Moore wrote:
> On 19 February 2013 13:40, Nick Coghlan (mailto:ncogh...@gmail.com)> wrote:
> > > If a tools wants to support metadata 2.0, it has to support all
> > > the complicated stuff as well, i.e. handle the requires fields,
> > > the environmen
On Friday, February 8, 2013 at 10:39 AM, Chris Withers wrote:
> Hi All,
>
> Just had a bit of an embarrassing incident in some code where I did:
>
> sometotal =+ somevalue
I'm guessing this gets parsed as sometotal = +somevalue
>
> I'm curious why this syntax is allowed? I'm sure there are good
On Tuesday, December 11, 2012 at 3:31 PM, Barry Warsaw wrote:
> On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote:
>
> > This PEP is also available on github:
> >
> > https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt
>
> wget returns some html gobbledygook. Why-oh-why github?!'
wget h
On Saturday, December 8, 2012 at 9:11 PM, Steven D'Aprano wrote:
> Why would a software package called "Spam" install a top-level module called
> "Jam" rather than "Spam"? Isn't the whole point of Python packages to solve
> this namespace problem?
>
Conflicts doesn't really solve file based confli
On Friday, December 7, 2012 at 8:33 PM, Nick Coghlan wrote:
> That's not what a Conflicts field is for. It's to allow a project to say
> *they don't support* installing in parallel with another package. It doesn't
> matter why it's unsupported, it's making a conflict perceived by the project
> e
On Thursday, December 6, 2012 at 6:28 AM, Vinay Sajip wrote:
> Donald Stufft gmail.com (http://gmail.com)> writes:
>
> Never mind the "Obsoletes" information - even the more useful "Requires-Dist"
> information is not exposed via PyPI, even though it appear
On Wednesday, December 5, 2012 at 6:18 PM, Barry Warsaw wrote:
> On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote:
>
> > If you're installing B you've prescribed trust to that author. If you don't
> > trust the author then why are you installing (and th
On Wednesday, December 5, 2012 at 4:10 PM, PJ Eby wrote:
> My point is that this can only work if the "obsoleting" is effectively
> just a rename, in which case the field should be "renames", or better
> still, "renamed-to" on the originating package.
Arguing over Obsoletes vs Renames is a massive
On Wednesday, December 5, 2012 at 2:13 AM, PJ Eby wrote:
> On Mon, Dec 3, 2012 at 2:43 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote:
> > How to use Obsoletes:
> >
> > The author of B decides A is obsolete.
> >
> > A releases an empty version of itself that Requires: B
> >
> > B Obsoletes:
On Tuesday, November 20, 2012 at 4:48 PM, PJ Eby wrote:
> Words
I agree that obsoletes is terrible, it's very specific and not something we
particularly require. I'd much rather just have a generic "conflicts". ___
Python-Dev mailing list
Python-Dev@pyth
On Monday, November 19, 2012 at 9:24 PM, Daniel Holth wrote:
> Mostly it seems a bit silly to have so much conversations about parts of the
> pep that remain unchanged from previously accepted versions...
Well, I think the PEP should describe what we expect to be implemented *shrug*.
Either we
On Monday, November 19, 2012 at 9:01 PM, Nick Coghlan wrote:
> Look more closely at the docs for "Obsoletes" in RPM, not just those for
> "Provides". Being able to transparently replace an existing package with a
> renamed one that installs files with the same names is certainly part of the
> pu
On Monday, November 19, 2012 at 8:35 PM, Toshio Kuratomi wrote:
> On Mon, Nov 19, 2012 at 07:49:41PM -0500, Donald Stufft wrote:
> > Other languages seem to get along fine without it. Even the OS
> > managers which have it don't allow it to be used to masquerade
> > a
ould prefer to leave it alone.
>
> Daniel Holth
>
> On Nov 19, 2012, at 7:49 PM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
>
> > Other languages seem to get along fine without it. Even the OS
> > managers which have it don't allow it to be used t
On Monday, November 19, 2012 at 8:08 PM, Daniel Holth wrote:
> The distro repos are centrally managed, too. Try getting setuptools to
> provide a virtual package just because you want to fork.. and then update the
> dependent packages?
>
> Daniel Holth
Sorry didn't mean to make it sound like I t
Other languages seem to get along fine without it. Even the OS
managers which have it don't allow it to be used to masquerade
as another project, only to make generic virtual packages (e.g. "email").
On Monday, November 19, 2012 at 7:43 PM, Daniel Holth wrote:
> Does it really have baggage? I t
On Monday, November 19, 2012 at 7:37 PM, PJ Eby wrote:
> Can we maybe kill Provides-Dist and its associated baggage first, though?
>
>
I would love to kill Provides-Dist. The biggest question there is how do you
handle it's
functionality? If someone needs setuptools but they have distribute ins
$ pypy -m timeit 'dict()'
10 loops, best of 3: 0.000811 usec per loop
$ pypy -m timeit '{}'
10 loops, best of 3: 0.000809 usec per loop
$ pypy -m timeit 'def md(**kw): return kw; md()'
1 loops, best of 3: 0.0182 usec per loop
$ pypy -m timeit -s 'def md(**kw): return
Distutils is not good enough for the vast majority of people. Even for what it
does, it does not do it well. It is a library that is user hostile and buggy.
It was
a fine first revision of packaging, but the Python community needs something
better.
On Tuesday, November 13, 2012 at 11:31 AM, a.c
On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote:
> Description: is the only multi-line field in the metadata. It is
> almost never needed at runtime. It would be great for performance and
> simplify the parser to just put it in another file.
License also can be multiline I believe,
On Friday, September 14, 2012 at 12:30 PM, Daniel Holth wrote:
> Add to metadata 1.3:
>
> Description-File: README(\..+)?
>
> Meaning the description should be read from a file in the same
> directory as PKG-INFO or METADATA (including in the .dist-info
> directories) and we strongly recommend it
On Thursday, September 13, 2012 at 7:32 AM, Tarek Ziadé wrote:
>
> Yeah but we've been too ambitious.
>
> Here's my proposal - actually it's Nick's proposal but I want to make
> sure we're on the same
> page wrt steps, and I think that addresses Antoine concerns
>
> 1. create a new package,
On Thursday, September 13, 2012 at 5:38 AM, Antoine Pitrou wrote:
> Most people use distutils / packaging as
> an application, not a library. If you provide only a subset of
> the necessary features, people won't use packaging.
Not that I think current usage patterns matter since moving from setup
On Friday, August 31, 2012 at 6:48 AM, "Martin v. Löwis" wrote:
> 3. There should be a specification of how collisions between extension
> fields and standard fields are resolved. E.g. if I have
>
> Extension: Home
> Home-page: http://www.python.org
>
> is Home-page the extension field or the P
On Tuesday, August 28, 2012 at 11:07 AM, "Martin v. Löwis" wrote:
> > What happens when it expires? Is that name freed up for future use?
>
>
> Yes, exactly.
>
> > I
> > think that freeing up the name is likely to be a bad idea since we can't go
> > backwards in time (as you alluded to lat
On Tuesday, August 28, 2012 at 11:05 AM, Nick Coghlan wrote:
> On Wed, Aug 29, 2012 at 12:53 AM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
>
> Please, don't. The software and infrastructure to run PyPI exists.
> Some level of namespacing makes sense to se
On Tuesday, August 28, 2012 at 10:43 AM, "Martin v. Löwis" wrote:
>
> I'm happy for PyPI to host such a registry. A specificaion for the
> registry should be part of the PEP for the 1.3 format, but I would
> propose this structure (without having researched in detail what
> other registries f
On Tuesday, August 28, 2012 at 9:41 AM, Nick Coghlan wrote:
>
> The only thing I really care about is the namespacing, for the same
> reasons the IETF wrote RFC 6648, as Petri linked earlier [1].
> Establishing proper name registration rules can categorically
> eliminate a bunch of problems furthe
On Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote:
>
> It does have the advantage that tools for manipulating the format can
> remain dumber, but that doesn't seem like *that* much of an advantage,
> especially since any such benefit could be eliminated completely by
> just switching to a
On Tuesday, August 28, 2012 at 9:09 AM, Nick Coghlan wrote:
> On Tue, Aug 28, 2012 at 10:57 PM, Daniel Holth (mailto:dho...@gmail.com)> wrote:
> > How about
> >
> > Extensions are fields that start with a pypi-registered name followed
> > by a hyphen. A file that contains extension fields declare
On Tuesday, August 28, 2012 at 8:28 AM, Nick Coghlan wrote:
>
> Agreed, and this is the kind of thing a v1.3 metadata PEP could
> define. It just needs to be properly namespaced, and the obvious
> namespacing mechanism is PyPI project names.
The biggest reason I have against namespacing them is i
I personally think that at a minimum we should have X-Fields that
get moved into the normal METADATA file, and personally I would
prefer to just drop the X- prefix completely.
I think any spec which doesn't include first class support for
extending it with new metadata is going to essentially kic
On Friday, June 22, 2012 at 4:55 PM, Terry Reedy wrote:
>
> Every time windows users download and install a binary, they are taking
> a chance. I try to use a bit more sense than some people, but I know it
> is not risk free. There *is* a third party site that builds installers,
> but should I
Not at the moment, but I could gather them up and make them public later today.
They
are very rough draft at the moment.
On Friday, June 22, 2012 at 1:09 PM, Alexandre Zani wrote:
> On Fri, Jun 22, 2012 at 9:56 AM, Donald Stufft (mailto:donald.stu...@gmail.com)> wrote:
> > On Fri
On Friday, June 22, 2012 at 12:54 PM, Alexandre Zani wrote:
>
> Key distribution is the real issue though. If there isn't a key
> distribution infrastructure in place, we might as well not bother with
> signatures. PyPI could issue x509 certs to packagers. You wouldn't be
> able to verify that the
Ideally authors will be signing their packages (using gpg keys). Of course
how to distribute keys is an exercise left to the reader.
On Friday, June 22, 2012 at 11:48 AM, Vinay Sajip wrote:
> v.loewis.de (http://v.loewis.de)> writes:
>
> >
> > See above. Also notice that such signing is alre
On Friday, June 22, 2012 at 6:20 AM, David Cournapeau wrote:
> If by manifest you mean the build manifest, then that's not desirable:
> the manifest contains the explicit filenames, and those are
> platform/environment specific. You don't want this to be user-facing.
>
It appears I misunderstood t
On Friday, June 22, 2012 at 5:52 AM, Dag Sverre Seljebotn wrote:
>
> The reason PyPI isn't one big security risk is that packages are built
> from source, and so you can have some confidence that backdoors would be
> noticed and highlighted by somebody.
>
> Having a common standards for bina
On Friday, June 22, 2012 at 5:22 AM, Dag Sverre Seljebotn wrote:
>
> What Bento does is have one metadata file for the source-package, and
> another metadata file (manifest) for the built-package. The latter is
> normally generated by the build process (but follows a standard
> nevertheless). Then
I think json probably makes the most sense, it's already part of the stdlib for
2.6+
and while it has some issues with human editablity, there's no reason why this
json
file couldn't be auto generated from another data structure by the "package
creation tool"
that exists outside of the stdlib (o
On Friday, June 22, 2012 at 1:05 AM, Nick Coghlan wrote:
>
> - I reject setup.cfg, as I believe ini-style configuration files are
> not appropriate for a metadata format that needs to include file
> listings and code fragments
>
> - I reject bento.info (http://bento.info), as I think if we accept
On Thursday, June 21, 2012 at 7:34 PM, Alex Clark wrote:
> Hi,
>
> On 6/21/12 5:38 PM, Donald Stufft wrote:
> > On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
> > > End users should not need packaging tools on their machines.
> >
> > Sort of riffing
On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote:
> End users should not need packaging tools on their machines.
>
Sort of riffing on this idea, I cannot seem to find a specification for what a
Python
package actually is. Maybe the first effort should focus on this instead of
arguing one
On Wednesday, June 20, 2012 at 2:36 AM, Victor Stinner wrote:
> What is the status of the third party module on PyPI (distutils2)?
> Does it contain all fixes done in the packaging module? Does it have
> exactly the same API? Does it support Python 2.5 to 3.3, or maybe also
> 2.4?
>
> How is the d
On Tuesday, March 13, 2012 at 9:31 AM, Paul Moore wrote:
> On 13 March 2012 03:48, C. Titus Brown mailto:c...@msu.edu)>
> wrote:
> > I feel like there's a middle ground where stable, long-term go-to modules
> > could
> > be mentioned, though. I don't spend a lot of time browsing PyPI, but I
> >
nuary 20, 2012 at 5:11 PM, Terry Reedy wrote:
> On 1/20/2012 2:51 PM, Donald Stufft wrote:
>
> > I think the counting collision is at best a bandaid and not a proper fix
> > stemmed from a desire to not break existing applications on a bugfix
> > release ...
> >
On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/20/2012 02:04 PM, Donald Stufft wrote:
>
> > Even if a MemoryException is raised I believe that is still a
> > fundamental change in the docume
Even if a MemoryException is raised I believe that is still a fundamental
change in the documented contract of dictionary API. I don't believe there is a
way to fix this without breaking someones application. The major differences I
see between the two solutions is that counting will break peopl
I don't always post to python-dev, but when I do I ask for braces.
On Friday, December 9, 2011 at 4:43 PM, Antoine Pitrou wrote:
>
> Dear Cedric,
>
> I'm guessing you drank too much (perhaps you are training for New Year's
> Eve), ate some bad sausages or are simply very self-complacent.
> py
401 - 497 of 497 matches
Mail list logo
