On 16 August 2016 at 05:09, Donald Stufft wrote:
> Hello!
>
> I'd like to restrict what folks can upload to PyPI in an effort to help narrow
> the scope down and to enable more a more consistent experience for everyone.
>
> First off, we currently allow people to upload sdist, bdist_wheel, bdist_e
On 23 August 2016 at 06:53, wrote:
>> The rationale for why the Windows formats get to stay when the other
>> platform specific formats are being dropped is implied by that last
>> line: we're expecting users on other platforms to be more comfortable
>> with using platform specific tooling to man
> The rationale for why the Windows formats get to stay when the other
> platform specific formats are being dropped is implied by that last
> line: we're expecting users on other platforms to be more comfortable
> with using platform specific tooling to manage platform specific
> formats (e.g. the
Thanks for sharing! I'm not planning on implementing any of this any time
soon if ever but wanted to share the ideas.
On Mon, Aug 22, 2016, 13:59 Wes Turner wrote:
> These docs explain the challeges of supporting caching with ETags, Gzip,
> and conditional requests:
>
> https://chibisov.github.i
That is the right place for issues with the backport; note that as a
backport new features and issues that also exist in CPython's
master/tip branch should be reported to the python bugtracker, where
Paul pointed you.
Cheers,
Rob
On 22 August 2016 at 21:25, Cosimo Lupo wrote:
> Hello,
>
> Sorry
These docs explain the challeges of supporting caching with ETags, Gzip,
and conditional requests:
https://chibisov.github.io/drf-extensions/docs/#gzipped-etags
On Monday, August 22, 2016, Donald Stufft wrote:
>
> On Aug 22, 2016, at 11:12 AM, Daniel Holth > wrote:
>
> The 'multiple versions
On Monday, August 22, 2016, Daniel Holth wrote:
> Some obvious ideas about how to enable greater compression for pypi,
> should anyone be motivated enough to do so.
>
> 1. If it's a zip, nested zips like so,
>
> setup.py
> README
> (metadata)
> data.zip
>
> The metadata is easy to get to, and eve
On 22 August 2016 at 16:49, Nick Coghlan wrote:
> - encouraging use of Windows Package Management over manual installer
> execution
>
> The rationale for why the Windows formats get to stay when the other
> platform specific formats are being dropped is implied by that last
> line: we're expectin
On 23 August 2016 at 00:46, Donald Stufft wrote:
>
>> On Aug 22, 2016, at 7:14 AM, Nick Coghlan wrote:
>>
>> Thanks, that's good info that shows I was clearly being unduly
>> pessimistic about toolchain compatibility. It means the only salient
>> technical difference we're aware of between the tw
> On Aug 22, 2016, at 11:12 AM, Daniel Holth wrote:
>
> The 'multiple versions with different compression algorithms' idea assumes
> some consumers don't have .xz and would prefer the .gz version for example.
The more variants a file has, the less likely a cache hit is for any given
request.
In the example setup.py would at least do the nested unzipping, but you
would not be able to patch before running setup.py. Also expect disruption
from future sdists that don't have setup.py. Both changes if implemented
would surely be opt-in per dist and would not break everything all at once.
Of
> On Aug 22, 2016, at 10:29 AM, Daniel Holth wrote:
>
> pypi is now free to re-compress without additional input from the publisher.
> Both .gz and .lzma versions etc. could be offered.
I am not opposed to changes to the file format to enable better compression,
that being said I’m not parti
On Aug 22, 2016, at 02:29 PM, Daniel Holth wrote:
>1. If it's a zip, nested zips like so,
>
>setup.py
>README
>(metadata)
>data.zip
That would be much more disruptive to downstream consumers of sdists.
Cheers,
-Barry
pgpcWwl_cnoP1.pgp
Description: OpenPGP digital signature
> On Aug 22, 2016, at 7:14 AM, Nick Coghlan wrote:
>
> Thanks, that's good info that shows I was clearly being unduly
> pessimistic about toolchain compatibility. It means the only salient
> technical difference we're aware of between the two formats is that
> the distutils and setuptools defaul
Some obvious ideas about how to enable greater compression for pypi, should
anyone be motivated enough to do so.
1. If it's a zip, nested zips like so,
setup.py
README
(metadata)
data.zip
The metadata is easy to get to, and everything else requires a second
unpack operation. data.zip is stored,
On Aug 22, 2016, at 09:14 PM, Nick Coghlan wrote:
>In that case, perhaps the way to go for sdists (at least for now)
>would be to continue allowing both .tar.gz and .zip, but disallow
>uploading both of them for any given release?
I'd prefer allowing uploading of both formats for now, with mild e
On 22 August 2016 at 09:03, Nathaniel Smith wrote:
> On Aug 21, 2016 9:18 AM, "Nick Coghlan" wrote:
>>
> [...]
>> By contrast, I *know* Linux distros are in the habit of pulling
>> release tarballs from PyPI and feeding them directly into their
>> release pipelines, so the potential for unanticip
Thanks for your reply, I'll try that then.
Cheers,
Cosimo
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On 22 August 2016 at 10:25, Cosimo Lupo wrote:
> Sorry if this is not the right place to ask this sorts of questions.
>
> The PyPI page for unittest2 package links to
> https://code.google.com/archive/p/unittest-ext/issues as its "issue
> tracker", however the Google Code pages seems to be read-on
Hello,
Sorry if this is not the right place to ask this sorts of questions.
The PyPI page for unittest2 package links to
https://code.google.com/archive/p/unittest-ext/issues as its "issue
tracker", however the Google Code pages seems to be read-only nowadays, so
I can't open new issues there.
I
I think that Thomas' proposal makes sense.
I would be ok to also add it to setuptools so that it can be used sooner by
projects that don't require python 3.6.
Sylvain
On Mon, Aug 22, 2016 at 9:23 AM, wrote:
> Changing packaging by updating the standard library will fail. It’s been
> attempted
Changing packaging by updating the standard library will fail. It’s been
attempted.
The inherent problem is you need to fix packaging for people already using
python, which means if you add a feature to the standard library, only the
people who always run the latest and greatest can ever us
22 matches
Mail list logo
