[Distutils] Re: Update PEP 508 to allow version specifiers

[Tres Seaver]

On 1/29/19 9:43 AM, Paul Moore wrote:
>  And when they start adding
> version numbers to that (like the OP's package >= 10.0 @
> https://github.com/owner/package.git) I can't even begin to understand
> what they think it might mean. (Hence my original request for a better
> explanation of the expected semantics!)

One might construe the request as a requirement to search the 'releases' or
'tags' page of a github repository, using some to-be-defined heuristic to
map the release / tag names onto versioned project names.  It wouldn't work
for the general case (tags / releases can have arbitrary names).  Maybe
*worse* is that the tags / releases can be removed / replaced.


Tres.
-- 
=======
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
https://mail.python.org/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/archives/list/distutils-sig@python.org/message/6XU53MNIFOTANLXCA2GK7VFHBWMH2Q46/

Re: [Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3

[Tres Seaver]

On 12/05/2017 11:39 AM, Dustin Ingram wrote:
> Hi all,
> 
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
> 
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
> 
> * Motivate and describe the addition of the new fields or changes to
> existing fields;
> * Point to the Core Metadata Specifications reference document as the
> canonical source for the specification.
> 
> Previous discussions:
> * https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html
> * https://github.com/python/peps/issues/388

LGTM.


Tres.
-- 
=======
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Entry points: specifying and caching

[Tres Seaver]

On 10/19/2017 04:57 PM, Donald Stufft wrote:

> Because the feature is unrelated to packaging other than the fact we
> currently utilize it for console_scripts.
That seems like an odd perspective.  Console scripts may be the only bit of
entry points which is used *by the packaging system* at installation time,
but an system composed of separately-installable packages providing shared
services needs some way of querying those services at runtime, which is
what all the *other* uses of entry points represent.  Having the packaging
system register those services at installation time (even if it doesn't
care otherwise about them) seems pretty reasonable to me.


Tres.
-- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPi’s predictable download url

[Tres Seaver]

On 07/25/2017 05:25 PM, Noah Kantrowitz wrote:
> 
>> On Jul 25, 2017, at 2:15 PM, Wes Turner <wes.tur...@gmail.com> wrote:
>>
>>
>>
>> On Tuesday, July 25, 2017, Alexander Belopolsky 
>> <alexander.belopol...@gmail.com> wrote:
>> On Tue, Jul 25, 2017 at 4:18 PM, Nick Timkovich <prometheus...@gmail.com> 
>> wrote:
>> ..
>>> That's because curl is kinda annoying and doesn't follow redirects by
>>> default:
>>>
>>> $ curl -i http://pypi.python.org/pypi/virtualenv/json
>>> HTTP/1.1 301 Moved Permanently
>>> ...
>>
>> Well, http://pypi.org/.. which is presumably the home of the latest
>> PyPI returns 403:
>>
>> $ curl -i http://pypi.org/pypi/virtualenv/json
>> HTTP/1.1 403 SSL is required
>> ...
>>
>> This suggests that redirects are considered to be legacy and may not
>> be supported in the future.
>>
>> Here are the warehouse routes:
>> https://github.com/pypa/warehouse/blob/master/warehouse/routes.py
>>
>> Why do you need an http to https redirect?
> 
> To explain this: pypi.org is on the HSTS preload list so all major
> browsers will automatically use HTTPS for it no matter what. cURL does
> not support this feature.
Seems like having an unconditional HTTP->HTTPS redirect in place would be a
"good neighbor" kind of thing (and belt-and-suspenders, as well).


Tres.
-- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Trove classifiers for MicroPython?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/20/2016 05:43 AM, Radomir Dopieralski wrote:

> I'm not sure this is the right place to write to propose new trove
> classifiers for PyPi -- if it's not, what would be the right place? If
> this is it, then please read below.

This is definitely the correct location:  the former 'catalog-sig' list
is retired.

> The MicroPython project is quickly growing and becoming more mature,
> and as that happens, the number of 3rd-party libraries for it grows.
> Many of those libraries get uploaded to PyPi, as you can check by
> searching for "micropython". MicroPython has even its own version of
> "pip", called "upip", that can be used to install those libraries.
> 
> However, there is as of yet no way to mark that a library is written
> for that particular flavor of Python, as there are no trove
> classifiers for it. I would like to propose adding a number of
> classifiers to amend that situation:
> 
> For the MicroPython itself:
> 
> Programming Language :: Python :: Implementation :: MicroPython

+1 for this one.

> For the hardware it runs on:
> 
> Operating System :: Baremetal Environment :: Microcontroller 
> Environment :: Microcontroller :: PyBoard Environment ::
> Microcontroller :: ESP8266 Environment :: Microcontroller ::
> Micro:bit Environment :: Microcontroller :: WiPy Environment ::
> Microcontroller :: LoPy Environment :: Microcontroller :: OpenMV
> 
> I'm not sure if the latter makes sense, but it would certainly be nice
> to be able to indicate in a machine-parseable way on which platforms
> the code works.

Are there actual binary wheels being uploaded which compiled for specific
boards?  Or is it that the packages depend at runtime on board-specific
features?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJYCNk3AAoJEPKpaDSJE9HYsl8P/2VBfoIqIE/NU4+zxfjV4pX5
nwnrnjxjfHEGIibmdhM0wh6CouaqqhaWdmgMKu66UoZVmJFiE/WAPYmHhcC0jHSC
Mk699B5+fZATywJp/NweaogpcaJiEvJEpcostD4Z15sfmzYCrrOZ4ylDSPq1+D98
ypQRhRjxjrMu9RxIOOJFOKHbvyHZ+NThAgvF7e7sDG5SVWeEPVN9ga8+F9B6JJjw
0Wgo0G/pTrTikVr/HSAbpkiQZRey4rhaN6hg5y0C4O2M/Sf4zrik0BfC8eWt23HY
tIT2EFhr5NR/9JaFYWkgZmrVFf23JJezS/1N6zGVKFIaf7AsCGh1LFy8jZNYuA7P
7uNzPM+9otgPp7Vx5w/rLKQXN2MlUKAZmX1FoUz5MBL3m7RaCctYMbxOaxxjXEJy
vORr1r7iOm9kw9YXIuVrtI5X9d+518IQ3Ege4JxhIhi+V90j6ht1wAXoGdLCqYNJ
OqrMbayhEatzj9dWu+3P5CrzyEfe2frahdBcms+PT/uDNKXA4SJBEibHYfv16yWb
Z26mx3sD3R65ceRl7wCgYy4G3rt1DTro2/LGfm2f92HHdmIHNWJI5sPcJSst9n69
1AdLZU6N/PSS3k5LRLia4GnTVfBJBxphTfywIcP81kHNLUvBvnX5bQhLnYAGL4Yj
l3sj1cK2n4dhWhvDLYds
=nBUj
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Deprecating PyPI as an OpenID Provider

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/07/2016 04:24 PM, Ian Cordasco wrote:
> On Tue, Jun 7, 2016 at 2:59 PM, Donald Stufft <don...@stufft.io>
> wrote:
>> Longer term, Python should get a centralized Sign on across all it’s
>> web properties, which could re-implement this feature for folks who
>> want it.
> 
> I agree. This is should be a goal for the PSF. This would help with 
> elections and a number of other things as well. I think there are a 
> few solutions like FreeIPA if anyone on this list is interested in 
> looking into helping the PSF implement this.

IIRC, Christian Heimes works on FreeIPA in his day job for RedHat.


Tres.
- -- 
=======
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXVy+lAAoJEPKpaDSJE9HYIBcQAImzTHtAzENNR//GswKjxrCT
zYxSQzdsQtBjpWOB279roeHfpZRSf6xhy9HjUhOWGIQ+nDgEcIgDUIU1BIg2ZPgJ
zQcMcjV0wiOAeyeVdgRtKXw3o4UW4XijuS43C29s+rxHvGPLPziQGQLWk7SZdzjf
YAi12Us96rj2m0uuXjpOPVZjrztI0ABdcA2yRJuDYiMtVONH/4TP86n6NHnUznO1
RCoPsfLTn7BbU1hMDOdrGKOED4QYNskiDAiB5qtL/uB8zDgKRLlIhxTHq9/d2T7D
0836zTvNwoo/TwBwfUFn1Op8CXydls7yGfpRq43NNqgBNwhWxzImpfVTxB+D8MHm
NCd4tPvgSJdyov2loYqToCytH3d+ueKdL77PG9ag7GCuOcrTggbBLhG5aaNknOSo
LN/yZgF+geuGp81WlHNwl3duo0JgapX/ilQg96IZSy19DzZa4/mihJu1SurGB53u
Jj7bpz10wCBMK5NJqzFYJ/gcAEqPQ7E6jzFQps65Eqs3HQTb33xOryptpmc7kZSR
fT/NJG+0ctwjdAbr7pZX0Jyg8G2hWEOsi+pfY/22Ejs4gxmNnMWqqVcLzBm7glB2
sDc4sm573WtDRM6+dkCyyjKZMYwvWSbsIlWiIo27pdHXOTx4fGKxiJgqt4cD1IhC
DN02co6A9A+t5Meory24
=fMAO
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Accessing tests_require and setup_requires from the setup.py

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/03/2016 09:58 AM, Daniel Holth wrote:
> Here is how you can write setup_requires and test_requires to a file,
> by adding a plugin to egg_info.writers in setuptools.

FWIW, eggtestinfo is an 'egg_info.writers' plugin which dumps
test-related metadata to a text file:

 https://pypi.python.org/pypi/eggtestinfo


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXUdRpAAoJEPKpaDSJE9HYQhsP/jrMq4q1BgCCMCaazvo9B4vX
uS9uzHj+T2noHwMcluSQB9zdSvCufNbKSoXQ62MUkbPEKwa1TarKzm+XZci/tBba
eOxwEPilHHRBF7no44ZTgo6kq27oOC9Z0em7F9awADxWmJ0mcgOksQTXjzczuP7h
BPoj1v/vxSLc87Q61qXYWMFTpiY4SjHn7+0xu7txQ13GJSaNjqNK/geQI+18Tpw2
76G0I1TDbXel+2JlgYEmwHkFPpFuhVaJXyJi8ZjvjdH/jN47oT6wsFwyxRzlVOXx
oFp//hdb05K9i2R9rdLznKzkrQCrlYUTEBXEIpMCacfnoHgKrn+MKHCdI4FXKXGz
Rm8LUh+oS0VU5IA8Rt4od08Qd68HE9CQERvx03JOQ7mKJIjxEODeC80JduzVGZxj
7YpA5sRxbsDTbnHD+8uodpFDDU0h9NMWLbxdDJ42Q1j2iNNr7ZZDR2tJZ8Y76EMl
55Mf5WZK5W+kzkUVodpK1yTxLR8+swadfjno2QnVhjA9h3vW1ZV11AREPTLauHbE
S+eoyN92ga4eyhZSwaQdhz6KsZgFpUcmhwvlrsl0dIlkkHs1mFjPL/J4PvR2SVKl
ug1Wmm0EvwPUQ0cDcRBeJtPF4git5SeMYLvGcMbsIpHdZloK+xaFVyMjgrTGA1o5
NTZokg2p47XvwuCA4XlH
=d2oJ
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPi upload fails with TypeError

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/20/2016 10:57 AM, Luí­s de Sousa via Distutils-SIG wrote:
> File "/usr/lib/python3.4/distutils/command/upload.py", line 139, in
> upload_file user_pass = (self.username + ":" +
> self.password).encode('ascii') TypeError: Can't convert 'NoneType'
> object to str implicitly
> 
> I verified that Topic :: Scientific/Engineering :: GIS is a valid
> topic. What else am I missing?

The TypeError is about the *last* line in the traceback:  One of
`self.username' or 'self.password' is set to 'None'.



Tres.
- -- 
=======
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXPz6FAAoJEPKpaDSJE9HYV68P/jlp6buHOZeaGdEVcSiPV/V6
l1FCk56Wgu8/IOjIA/APLH5USMfABESt9YHKBzMENfRQpIbaMs0CmhdE5ONeJs3F
LSOGEiY4i5QWNjOlw1oE5GaG9Hj31XuzmCMs39kIQ3C+gOXq/inGTIF4fsvGmK/l
dMfVEWmbG0OJkcclrgrTAiJ79La0408ci+N62hsz4s3l+d0F9PUZXd6gpl6AOzMm
ORr1IMsGHLfhyWFVfmWoJxyRUJVeGE+t3wY6CCOJEJEckbezOVXyxkBnkSxhVpwd
fwffKpNTwFRXvggH4qPcDmmf4T6sAS/hOkBBw0WjcbNMRlFzCaU7Ehr2aw3+wxjU
H8GAsn3Xh2H1T3c4qHUYWe7X78/mPN0Pri9Rykg9NVSJ9m1awq94tJgR7tH1om3U
+4UvzzkyIKIr8a8YikqSjKnTrJWhqtnSJ+08D4zlBoA1R7lQMdD079wOnmtaLKYj
ogYf9xG1jFpVWUeCOdh6qHlQikBHWFWRFSMootKg/tRd6qrsLsbaoaIlEGefPEtJ
NgOQ1wMYWthzGglkiktGF7Fv6qHit0rYVSOOSu7gIxQbpkgOylaIwGDuvkArELk3
WD1AJ/F2gc409/IhrvJITP5rP+sdJVMtJswEqYvB6zxaUURvt+Qf4crzqPUCvrAp
aKxqMdnFeKZ5jqKRrXge
=Ov3n
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Name arbitration on PyPI - how about administrative abandonment/replacement meta-data

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/20/2016 04:36 PM, Ronny Pfannschmidt wrote:

> its not given lightly, and it shouldn't be easy to weasel out of it. 
> Actually a noop release is a good indicator that the mark is
> well-deserved and should be keept. Making an effort to remove a mark
> without making the reason for its existence go as well is a lie in
> plain sight.

A release, any release, is a sign that the maintainer is around and cares
about the package enough to act.  That should be sufficient to block any
takeover attempt.

> this reminds me of the whole setuptools/distribute situation.

I don't think that means what you think it does:  the situation was
resolved amicably, via negotiation with the owner of the original name.
The fact that it took longer than some wanted was *not* an indication
that it was the wrong outcome.



Tres.
- -- 
=======
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXGAaCAAoJEPKpaDSJE9HY3FIQAL87jOyqytF1MuC5SHqiw0y1
p7BYWrLf8MVl+DFRJ0x0s9NPVgvkeF+rbx17WD7k8Eik5iuXzTpjIun0oI9UBkwC
iTpogEwDrFg3T/s3bM0ObAphcLFHAY4YFMXsUThODtCHg4qi/04Z9RiMhnabwitP
GfzuI33aDZbgkyi3ozEse5rP1xTn3SmhtHwu7k5gQvAmg8ntpXFzP7l1IXNWtPr+
SGXzsgohZwsDdOBwOibbvQ3VQSmeLBPrfsP0xVzNOIh7GEHT6AXMM8qK52Er4vMd
SQmR2r0WAShqDm+LadfK/KjrvwSgQILpp1z4jvY6k3PWhtLABEeotDZj5mgRY8Hf
0+NTBuifYo7SHs+ElI4nryDbp48q2DZH2PLdh3WgyMlLzTocXTjQcwOTEZGcbb7t
s5u+/cQLzfvg4Z23i7wPGrUrBZvl4YM3YKZfsC3Pl5v9jfwiJm/ay7G7O2NHstdB
inI23H427ELXgPLI8Ffi9u7MQ6zTCd0H/XNxaiWAhG4JmMZyFuNqJQAuZ9+cR9N+
WWPEpfpHhWW9pYdxKWPHJLWKoGTu+6qPqIMnCPn3sY8ACnqH7z5puNu+/uAJ3hBt
PNVh+wKE4R1wNXHKHaHqVqMH/Ut057hEh3EIOwX5e8W/zCojZy8O6PjmaFW7EGdd
BMtyIkp2jgQJMY3ClfP6
=w60N
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/2016 04:17 PM, Alex Grönholm wrote:

> I think an ideal solution would be to add a feature to Warehouse that
> would "redirect" any downloads of a library to another. Though I'm not
> saying it would be simple.

Such a feature would be doing a huge disservice:  repeatability *matters*
for package consumers.  Unless an already-uploaded package is known to
contain malware, or the author is under force majeur compulsion
(governmental / legal injunction), removing a distribution is much worse
than giving the humans involved flexibility to deal with an issue.


Tres.
- -- 
=======
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXBDaKAAoJEPKpaDSJE9HYGYsP/AtJGhNFXPXjtUlTVoDHw6oz
ohzb5js31Dps86V/CQELl4cxFhfPMpPCPxcfA9z/E9B4Wk3HaFTPxOUunZKrbUJA
2MguOnsYOjeWCBSlBEOdjCSTHiYse07NRMV4NN+b0mfdnj6VvTk17uY9UW96GTiN
xigRgysRgN71JnE41ZNL+4qKjvCL/6dYFrga21rdvOGnZrTNUBwP8mbbACrdz9lh
jeOSVkbWMqKazAXIZB3y7KaByIHIfes5fguBnsjqpgdL9c9r8WsE5nhBCdlkUm8N
NAiNEpTy+5G5o0NhGz/4AXFtamkVLTGSZhWcUprHOtJUgjzer+b0WWijFcBtcQGY
Ugbijhotlbx+zI/QPqArqDemU++UhGr+oiI839KfyzV3viZ4MEr8jC/BchM88Jmn
8lR3Fyv25Tc2bDTC96hv8A5zcwM08i5FYHlPhW2a96xue5Vl9wZ6rmpRUTtqhErJ
vwPu/Yps/l1nXzRXPc8NcHTH8daDVIgaNNp8EeDHV+vYJgy066zzzSQ4dTJddWbZ
mcf6aFQDP50vrloZ81GaeByUJ1xlcVfyODdvpKj350YlqPqyv7y7uMJv026csRax
l/3DyhChbqzU/be9f6xaGL+KzJU3Xt2L0XY/annNkBWrsbRKISpiiGc+21rNo23P
EB9Sax3Uoa47h5GWQWH5
=CblP
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] SOABI for Unicode ABI on 2.x (was: wheel 0.27.0 released)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/06/2016 05:35 AM, Marius Gedminas wrote:

> And people who run build Python 2.7 with './configure && make && make
> install'
> 
> Why does upstream Python default to UCS-2 builds on Linux anyway?

I don't recall if it had any bearing on the choice of default, but
Long-running processes with large quantities of mostly-8-bit-compatible
text strings in RAM (Zope, nearly any other Eurocentric webapp) need
measurably less memory with UCS-2.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJWt84xAAoJEPKpaDSJE9HY4KwP/jTTsxXJssYd/aPXkY3MSObU
BI4BpBvgHcQnyCGJ7gUqjS7MtHcHb0iz1ch3xAZy+lz/kXhB5+Kd6q9mad5altAa
RK9RK8+i4UcS4Mwd5KMKfXuaOygr/AyrZJ4C6vgNFgN1HKD3HhLtgJAwzeyk1HE+
5ZN2XEVUVhYeTUXdP+qCea3SuPf2O0zADBat/ys8JQ0MMKPscm5acKE5uum3w1eJ
2nrF/8EP+LgZFw/3WNQON8tWKz9Iqwmqr4022jorOi6yq0OG/MAPzjNuSDZ6Ab9t
klyDVbVVuFVdiPVhMd9viaoYJ5Q2DoFJG0jnt58B8L5N7M0wn4UTT/ZX5vvZJNoJ
GqoavyWiFbLEu3+btlInkTioGYhNtwZKZnTH63Gjri2LAk5C4SmeD0vYiJMrHaCA
ySGTLwmv/SiTNvKI0kVQ0DcJ3WP4mHherq0bB6UeNEcD1MVuvTfjM8MSelrmo4VC
eJsvKfMcpZ0l3V5fX00AbE1TWTrz1DDojVzR2KH+uhUjzegZt0B68StOg3drxh94
f37Fs7CfenVsCGyThguZX/uZAtQulCDe/UNx/86cX+GuMNA5qifu8IIYb7UM/fIX
Itn3fjYpjC5fhRFLiUKR3yuv9h1eckgefRYINGzB2d3bZRnkT0IsurSbg6uvt+UE
ixNkskENFDuIQthyvCbQ
=u3iS
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Reviving PEP 470 - Removing External Hosting support on PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/27/2015 07:51 AM, Donald Stufft wrote:

 This leaves the user feeling annoyed that we didn’t just search those 
 locations by default. I truly think it is a bad experience and I only 
 ever added it because I wanted the discussion to be over with and I
 was trying to placate people by giving them a bad feature

I don't understand the sensibility here:  an error message which tells me
not hosted on PyPI, try 'pip...' instead seems like a *good* UX to me:
 Having a tool which respectw its default policy (trust only PyPI)
while giving me the information I need to off-road when needed is a good
balance.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJV3x+AAAoJEPKpaDSJE9HYE+IP/0LiQ+TwRnDvAcDsRG9wXPWd
l0D2jnw6uGkJez5CJD+4JA9x3SRabixY+K1VRffgnG8NuR0omfioJbAFXyQVV9g1
ymUEZzJG5O8kd7v+iIvrguu/dGu1hAH9nwsLQwAkPdrUSfB6YFIfBmJfpb3vqJAx
Frf6A2zAedwLGTB23XFajJBYpDXZGjwj1+N6zedDHvC0xfN+fRW3jyYwaTJYklDU
y7HZRuSIOuy6mRgjwi73iNsSexY+jcIyKWdh4msD6+BLge8X1/8BuDtA5Q5agMrH
ZxrlHaVv5AxtDks6lYzIhSocK2D28NiU2IBbha8OC9NUnmJdNHVHmvmR4UNTjYTY
cP1+bi3cMQ28LVcuGffXoV4HlydpOf1QKIOaK6fwecr6ooIv2Y0/BJrSElgCrBZ6
tx3nP/uHd6R5GoxLl88ZyT7oFsoPQUVSsWZTc+1hnxI7PskvTAZXogUJShO0um+9
hKXjmc911fGKMszNk8xnagUMWJVimuBwLZwsVAjg9s0D5Xfq/LRS3qzs88Dwmb5C
FPpaJINqgSfWRkiivgIsO421PUuX+vyjLr13vcfCaN5TCwHQujgOe+6PFqOjjVNC
UONyy98A3RzdUuBuRruwzFUkaBRjqra7TMQrFzhHFIwOeiY/T2dMTRnMfAlC+TVO
hv5zjuS8U9/WqpiWH2zq
=a10G
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Working toward Linux wheel support

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/17/2015 11:46 AM, Antoine Pitrou wrote:

 Due to the fact Linux binary wheels don't exist, conda is even more 
 useful on Linux...

FWIW, they exist, they just can't be published to PyPI.  Private indexes
(where binary compatibility is a known quantity) work fine with them.

Because it nails down binary non-Python dependencies, conda (and similar
tools) do fit the bill for public distribution of Python projects which
have such build-time deps.

Even given the over-specified platform tags Nick suggests, linux wheels
won't fully work, because the build-time depes won't be satisfiable *by
pip*:  the burden will be on each project to attempt a build and then
spit out an error message trying to indicate the missing system package.

Is-that-'-dev'-or-'-devel'-I-need?'ly,


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVrbuhAAoJEPKpaDSJE9HY0R8P/jLBINO04/NTlJTUa8wmIxed
aWSU0mxFSAKg0q+n2QaRi418QG6vvtUVGsXGafmYu4hlfKj3Hkj6DA+ws2o7uR5S
1UNU3KSF2lsLoWjaIKpMm4RNWmbHuWQ3HlabXqSly7H7lfgXCAzntdrVy5s3zacM
4wqVTjTWaG2lBf77B6aWhgom6kTvfnpNtyQ4+oKDujSnSWlLJ1W7p0hvuR/33XHr
1NHUdaoUWH7kES0zcRHOyYU7PSPtVYMpzn3SKWljMXSiN1vs9YN6WmypNmLeXjTj
gkD/JR8gGv97o9TliKW6KaocbSLvZ5w2bHwkBGYsLRS2pti2ojw+3vmSpm4VwKyn
PLhOaMpBR4qC2scFVJ5z1iW9uOYlakra45o60rAaRTiuKEHBPaoimQP3mMW38AsB
glY+/j349A2XyE1vosAekxeuinip64erQg6G3+gU0myRsfaaC1lTBlzkDrsya4X5
C2LbE4n2IlMrm+hrA/RbUjKlbTJtIyWLlnrv1jORh6l5VNTXSkafStA7j1nXa/hx
4zAqv9mV/1UErI+IjPz6CQTwNbz5QtSP1gFa/9xqGnnrBSuWRMYd/x0c+JNXFzFC
MCMhbQ/ZIAkpmk/VRb1mVQVc2uqsWr9WxZ5F13cJJvZrvWkQJFf70nnHk+n2f3CU
9/s6HEGX8SkP8tZnZ7Co
=gpd9
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/07/2015 07:43 PM, Antoine Pitrou wrote:

 That's a dramatically uninformed statement, to put it politely...
 Some packages have difficult-to-meet build dependencies, and can also
 take a long time to do so.

In the general case, it is *exactly* those projects which are going to
trip people up when you upload their binary wheels to PyPI:  there will
be no way to know that the compiled-in stuff will work on any Linux,
and solving the problem of which Linux variants a given wheel can
support is intractable.

At least for performance-snesitev codes, building on an old,
least-common-denominator platform has been unsat:  squeezing out the
most peformance on a newer machine requires compiling on exactly that
platform, using the best compiler available for it (and maybe tweak
options differently than are even possible on the LCD platform).

 llvmlite, the package I'm talking about, builds against the 
 development libraries for LLVM 3.6 (a non-trivial download and
 install, assuming you can find binaries of that LLVM version for your
 OS version otherwise, count ~20 minutes to compile it with a
 modern quad-core CPU).  We regularly have bug reports from people
 failing to compile the package on Linux (and OS X), which is why we
 are considering the option of pre-built binary wheels (in addition to
 the conda packages we already provide, and which some people are
 reluctant to use).

A conda pacakge solves the problem by pinning all the underlying
non-Python dependencies to known-good versions, which makes it the
right choice for folks who cannot / won't build it themselves.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVnO/AAAoJEPKpaDSJE9HY01kQAJV3Jht+KBdBfWn9w5G+/bD9
/8XRweaHFl+jBhFc+NEKjZg1Nfcz+bF8PHvC/unsUF4hBMJyeMtAadutDYVvlbOb
hjUnY7BF94ssP1HcNJW9x7eQfKiwQqdOxr+4r15YkYGf0osW/JJ3SXYj/R9GwQ1c
d/ZlTFtbL+fZaEEwUHS8pr3J2hx9HELFPQI3VCdt7AomNqGMoM92UDPXcyOvLUTB
OfswrojVM2g1NJclvVEbd0FXIO/ScQeDYVd767LIynMbv4xQoB8/Bs9B1RBEj+gj
ZphfRFtGssEHiNKN0Txk9Z22aYqQhlmxiJJx4mqT5qaSyY15iG34WsBh3gwqaDvR
o2VaWMDAtxunqqiB2E1NXGzPH5InivalG1laPxYs2SZJMsYn0M3y0FDgNaV0vHuO
JC3U1ckVm/oeuLhmaHmi/qzfaFTAxo4JPPcTxYnAdhVWqmWOQJRz/q20acpUu7Cx
ZrezhYOVeDkF5AB+XyU6O4e7a0zB7r9jKKSIn/6EJHrMQ+l744U3nT+mJ31CIIO2
ZAYAm/ZOQK8MtSBAi9rVLzKmkyOAnUX/Fnil6uBYHAeBiIRy+BLExuzcT/0bNBXi
Gfhzky8/rw7RCdBUTHeWY1y+2cZpq3BzFDSZqXMPT79SA3I+kQ9wAyyRI0x5tB6s
0ujHYOv331tJooipuYrY
=JH2E
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/2015 07:10 AM, Antoine Pitrou wrote:

 Seriously, how this is even supposed to be relevant? The whole point
 is to produce best-effort packages that work on still-supported
 mainstream distros, not any arbitrary Linux setup.

I'm arguing that allowing PyPI uploads of binary wheels for Linux will be
actively harmful.  The chance that hundreds of project maintainers can
get the dance you are suggesting right is iffectively nil:  it requires
them to compile wheel only on some unspecified LCD platform which most of
them will have no access to.  Once uploaded, mis-built wheels will cause
no end of pain for the hapless users who try to use them.

conda *is* the right solution for distributing cross-platform binaries
for the relatively small in number (but not importance) hard-to-build
packages.

 Instead of lecturing people about what is in your opinion 
 intractable, how about you just shut up, if you don't have anything 
 constructive to contribute?

Really?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVnVhpAAoJEPKpaDSJE9HYnxIP/0b9dCEHarpzzzZP+fam04i2
a1sdxLn5RodGcUF9kid4KsdtOMc3D1sKf0yLbuBA7z1ctMYsPDYPcmvlo4cW2iSJ
WHYaBm1nJ1JUIxBDagWl5IhIO+aMtRmBQ+UnRj2vQi6Clga/d0M0T1+lNhAJy4hs
SogpFx3SayW+BotThqY1JGvAaKyM5hGYARAQIlrxWk2Ei6pff4mNAdXd3t1hjqg0
Y6PlBVCo9APFtbtO2AyzdVY5Mp4D6QqDcdj3NhjHsukvPTlpgv1dk+jJgPJfTxCw
Gx0Gv2Zt673y9QNOer6Lp3A/jkLG6w5mnY9K3lid+wx3Pv4wd3NNy+O2FuopKHZc
RdE1mWVe5W4ufSJVhdaXTOj5Eww9KnL5SH3KbTYBbDST7c9pFM0tnk/8Lq+4OU0z
soGCrZtH5mjof7LPDkvVh/j/mrLeRo+Wz9JsaAb8+PZVDuBSEfHKDxoKcmO0VzAx
weJE24eNfqCLzbQKhaIiXWA21D2jE1KxdUuzf0qJwwlkPaa4BmvMzJ0iKMeZYFf4
lYnBhNBJhZSGDTPpXRiM3Q73bzxvz3OYY/+6lcZU+LYx8LIHmQMrgHDddh2E9FvQ
BC4sfIBGt+LTbZPSsK0xp+MbX1yoW4TcXZeA/fe8/e2GY0UFgKQRD44Fa0hRdU7b
QXabMbyCHLKEKxc+xmXF
=Lrn9
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/06/2015 02:18 PM, Antoine Pitrou wrote:
 On Mon, 6 Jul 2015 19:03:19 +0100 Paul Moore p.f.mo...@gmail.com
 wrote:
 On 6 July 2015 at 17:24, Antoine Pitrou solip...@pitrou.net
 wrote:
 (yes, the version number is off - but that's besides the point
 here, I think):
 
 $ twine upload dist/llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl 
 /home/antoine/.local/lib/python3.4/site-packages/pkginfo/installed.py:53:
 UserWarning: No PKG-INFO found for package: pkginfo 
 warnings.warn('No PKG-INFO found for package: %s' %
 self.package_name) Uploading distributions to
 https://pypi.python.org/pypi Uploading
 llvmlite-0.0.0-py2.py3-none-linux_x86_64.whl HTTPError: 400 Client
 Error: Binary wheel for an unsupported platform
 
 PyPI does not support uploading binary wheels for Linux. This is a 
 deliberate restriction because the tags supported by the wheel spec 
 are not fine enough grained to specify compatibility between the 
 myriad of Linux variations. The intention is that once a resolution
 to that problem is found, this restriction will be lifted.
 
 What if packagers take care of working around the issue? (for example
 by building on a suitably old Linux platform, as we already do for
 Conda packages)

Compared to Windows, and even somewhat OS/X, the win for uploading wheels
to PyPI is miniscule:  pretty much everybody developing on Linux has or
can get the toolchain required to build a wheel from an sdist, and can
share those built wheels across the hosts she knows to be compatible.

A-foolish-consistency'ly,



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVnGGVAAoJEPKpaDSJE9HY5McP/0MCer5wS0MygSHw/UGrcvKN
2pDfGdFsucjY2cR5Wr/R28NEvTPzrmBghPAw4x47rNRpNWBOHvRMyOu3UWKJIeMI
r/elBcP9te26jA7o/clqkfnVNKGjcoDSis+YkyhZAfhEDNGXQAaSf8uNFsVDKMTj
W8ggxe0DraXHImE0X4rahu2a7Svd7yWIMtRv5eMP+HjfLA9ouQUuFNYXCuXDmTIS
5SJ+XkXjToKy0DSqPkknESVcCnF6sDjI1STo4dPi65QNlUQomv9m3TwLN9Ak+bx6
u0vM8R594PXMcb8cTnBXdmDbdDhQRym7Wy2Fr5zYs7nwJ8x13d2QKs5fQ/QhmUF5
DtyWeQekhK1+wupt6NQ8tXgu9jx9SV81XtvZSAp9SAVS9asC7BUjLAZEh9r3K07b
dTkaY719vFUioiYQazDjIrkMLxSKjGbBgkve78tkjDtfwvKDOBqofFEmcsBv8yh0
wA5/iYJ78Wmr2rti5d4/JwLU5Tc+NkkYcw1W0bRUgi+GX8vYtYQ03i36f33Kyf3f
z6n8rquZhGDIcPjbrEmveBJxErJTu/3ifuIy6NnTwCFmQNOl+HpqtJFtYS1a3NUR
0s9eivFgl6vwExN2KywYW9N/6tCcWyB0qvECG6tB/a+Ao3iW8KOciyyjaQZWwOFx
glybBbAdFgtqaLafaJnQ
=NgK8
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 'virtualenv -p jython' leaves 'pip' non-executable

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/2015 03:43 AM, Suresh V. wrote:
 Could it be your umask? Just wondering...
 

Nope.  This issue only affects the 'jython' environment -- all other tox
environments run fine.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVcECOAAoJEPKpaDSJE9HY73cP/ip5pY1NxhdOo0jAHACQxGGN
U4bhzcNm0Qy+WGHQfCfNnIVAVMNgAdFV1nfI1Uu6x4I4lS6Ljm5Q1lXn4k4SqHcg
ttGs1nDDuZYEYFooKKxOsLOWISwR7FTQct9tOUAZa+uu/a1uN8RyjwbB2/c6XOJU
HR0FYfIAn37yZ3I6pITFrC5cUJ3E2ddDZBjim7jHvWGgQaSb+5fjor1BRKzrVj46
L6nxLPLsaQeepJtWGvDr9OzIr4zfovhtSdLXOr7uCNrORk49VGQYETjk4hDenB2I
c/OFEFt+XTL5Rf95fTQNj7v04rd80witBTSN5xNEyIqYaduFinbql2gEmTkooqpc
cJCkBHpphHY5UJj9fnQPqVKQjRL0kaopWXg+4DGEqPu5Rj+V21Cn9BHad8flo4No
jjcwSFjRTqJdfc4uzQ20UMZFOkX01Ak/REO77MfxcywE8nqrRFqC8j8IS6gGKWAN
+k7/UjgoOzC0qzmjnYBGBXZH/UgQMPFEcIQ2HJ/o1G7vL9y6MocC2Hjc558YLfT6
+IiDmOrIErxV8oMWkarCoTFdW7aILim8AbCQ/XfUezVE3dNkbXuXf/VoUWrOutni
CMwpDTcwdZCvdqnwuE2/nEZcCQUTxyaVUorSERjsDGB3SWuInbYniepNqAPFQr0y
yaCBn3tBhnKGMIwmRku3
=GYVu
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] 'virtualenv -p jython' leaves 'pip' non-executable

[Tres Seaver]

:45 python2 - jython*
lrwxrwxrwx 1 tseaver tseaver 6 Jun  3 13:45 python2.7 - jython*
- -rw-rw-r-- 1 tseaver tseaver   218 Jun  3 13:46 wheel
-  % 

None of the scripts are being marked as executable.  I don't know whether
this is a virtualenv issue, a jython issue, or a setuptools issue.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVbz80AAoJEPKpaDSJE9HYg2EP/2sWlshPGokrrhOZYV/8YgcM
IFNa2JlwKNwPefKtQ7VThrIqYHCTo8UuLC+6mv1JFvXIT50dTubOFeLP2ddR9X1f
Ma5kqwlCs+lf1VhqWbA5BIkg+p3GH+l/CImudJOijxF2Lvlx1sHvIOTZwgU1qYvG
cpMAOW5D9rT34oU7SEf6mIGro8cGVa3nEMsp8optU7iOZTzvgQG1nyYknfBJquca
jwjwBOgrxaZkIaYrCyFWspR8sdPaWs+9S4qR7RsXkCWYHbfjtNKObJB4CPw4VdIV
S0M16pz+znrY3nBggrCFzLAyJQje2E5mwNF1BDMKCrWTbUbdLmpbWMdV0//A68kP
yricqNoH5Juw5PVCl5AiP49mIAvBUWipyD57kUVNP4ndlU23DMiC7/ClqS66HSw/
HCiThu50wVwZ4SYX/YOGmPorQKtmntLbLhGx2Oj1f74YoqVtcrTUbqeFG0MIW2W5
EU8IHy3k9n8hVacP9bm0zipUAX5/AJe+vS8eA+14B9pbU690hLK4pQZ8EYM2Dn87
mT7ii9IKgXUElybMWqR5v1w3kwbj/lRZbFqJ59x2cE0Kar1z5P95Eij6GgRP5sBw
6EdtK/35HVOk5K51Wkd7AWfVawSYRV9NoPxFFNcj3l5MqyQI0ewt85KpuYdeHYv3
w/9dWcP6PNXmDxA2VXA6
=eZat
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Released: pip 7.0 and virtualenv 13.0

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/22/2015 12:21 AM, Donald Stufft wrote:

 I'm happy to say that I've just cut the releases of pip 7.0 and
 virtualenv 13.0 and I have uploaded them to PyPI. For the full list of
 changes go visit the respective changelogs, however the biggest change
 here is that in pip 7.0 when pip finds and downloads a sdist, instead
 of installing that sdist directly it will instead build a wheel of
 that and cache it locally. From then on out it will use that cached
 wheel to install instead of downloading and building the sdist each
 time. This can have a profound impact upon installation speed.

Nice!

I was hoping that this release would make ;tox -e jython` finally work:
it's closer, but fails now due to the fact that the '.tox/jython/bin/pip'
script isn't set to executable.  I don't know whether that is an issue
with the pip bundled in Jython 2.7.0, or some other weirdness.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJVXxoyAAoJEPKpaDSJE9HYhjUP/RADiv/qM2xRg8UednYfxLub
1AUQk+GRYR4B1zbcNu/f8tcXeKePde7QaQ3si1EE123CBQxk85xqMH/2oYFqwCsw
Dxb7QuQdHhhuImxpM4SIVJmb0Tm8YqYIkDNH0NAuRVWkgaWQDfQgHVYlNQWxog/e
8hEnEWs3HjF+9+7GcTL7ny+l6CAmlh32zJaPQi0j+hzYbS54iShYzcWzlkSltFmU
N4LLIlel9SWyX0WclpeuP4hhygpPlkqAoMPmh73m1/74jk0My8qXC2UY5KwU/Iar
ugK3KOTAohpeTvbgK9wdIzOuqYoX6k0IgAHFejcbXWYoDNFUvS7HAqCoyCHA7JJJ
9SZsWRf8rCfaGEzWrAR3PVOMGmpLO4DuQBZZ3sypIRC2stTOtXzQc5gg0CjvHZjH
DVmjXF0/WBcngAnUdkDjIwZTxvQuR0NJEV7H6ODMNwO+UaBGTCojih1JDVG+GYW6
2uXUSAWBlX50zBph6U2GbouAwUbtzTlb8LWFdj/GIQ2UvNwoF4f84EougriXFAnl
ODkPxjHt0l9N8WIGfq2v32aHl+VsNgRMptZMV38fGxCSOGM6Eo/eUQgY2Qfcx8g7
wOUHcQRyTAs8AT0Dy++eOZNrdndvQFiYKUMIUzJJaeHuEbGaeKruiOva7/+65GNr
N90Y/+cw/feYl/eIOeP4
=Me4+
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Role of setuptools and eggs in modern distributing...

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/07/2015 07:20 PM, Chris Barker wrote:
 OK -- I just found the --no-deps option. So I can do what I want, but 
 still, I don't think it belongs there and all, and certainly would be 
 better to have the default be no-deps. Let pip (or conda, or...)
 handle that.

Unlike pip (which provides no API), setuptools is a library, used by e.g.
zc.buildout.  The behavior which you find objectionable (installing
dependencies needed to satisfy 'install_requires') is a core part of what
setuptools *does* -- ripping it out (or even changing the default) would
break nearly every other user of setuptools in the world.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlSupRIACgkQ+gerLs4ltQ5/fgCfZTk7b9+eVwLqJcztO1RggQJ2
XxkAoM0gYO+vV/sOrIcVqPFbCRVmAi+o
=gRN+
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Bilingual namespace package conundrum

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/01/2015 04:57 PM, Donald Stufft wrote:

 I’m pretty sure the problem with setup.py develop and setup.py install
 is because they are installed as eggs more or less and setuptools
 probably doesn’t support it. pip install whatever installs it
 unpacked so it’ll rely on built in importing.

I'm puzzled by that notion:  'setup.py develop' and 'setup.py install'
have worked for a decade with namespace packages, as long as the __init__
for them does the Right Thing (using either pkg_resources or pkgutil).

What has never worked properly is mixing pip installation of namespace
packages with easy_install installation of packages in the same
namespace:  pip's install in one directory without fixups stragedy
screws up the __path__ for the namespace packages installed elsewhere.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlSl/kEACgkQ+gerLs4ltQ4aYQCcDImoKfLr3Xb+tkFSY9x8Oinh
QT8AoNDKmxVoqdX3UMnsUg1ktZbqukZg
=CPP5
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Bilingual namespace package conundrum

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/01/2015 02:19 PM, Barry Warsaw wrote:
 Maybe the sys.hexversion guards should be removed so that it acts the
 same way in both Python 2 and Python 3.

That sounds right to me.  I never really understood the motivation for
PEP 420, but if the presence of that file disables it, then it should
ensure the old behavior regardless.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlSlq/oACgkQ+gerLs4ltQ5hjgCeKMfXT0DPBS//0y/XAP2npJRW
KssAniyBjuuhjVpw0ETola6v6hVuwpiP
=BLOQ
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: using /etc/os-release in the platform tag definition for wheel files

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/29/2014 11:10 AM, Antoine Pitrou wrote:

 For me practicality means being able to build a single binary package 
 for all recent Linux distros in a best effort approach.

I can't imagine finding any such binary useful (assuming a
none-pure-Python project):  the chance that it *might* blow up makes it
easier just to create my own from the sdist.  Such binaries would tend to
bitrot, even if they were OK for the supported set of distros at the
time they were made.

How can such wheels be feasible, when cross-distro RPMs / .debs are
clearly not (in the general sense)?



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlR6BMUACgkQ+gerLs4ltQ70sgCeJ8BmRVDOhEzJ4I70eGWQCLn4
l0cAoJwoHcC26M/t5mhLXgJl4IrugDcV
=G5zd
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] some questions about PEP470

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/14/2014 09:15 PM, Donald Stufft wrote:
 On Oct 14, 2014, at 8:50 PM, Stefan Krah stefank...@freenet.de
 wrote:
 
 Donald Stufft donald at stufft.io writes:
 
 If you're this upset over someone redistributing your work,
 then maybe Open Source Software is the wrong hobby for you.
 
 Usually one does not tell a core developer that his contributions
 are a hobby.  I have contributed 4+ lines of original, dense
 C code, backed by 100% code coverage and 3+ lines of ACL2
 proofs.
 Uhh, maybe you’re misunderstanding the word hobby, unless you’re
 getting paid for your OSS work you’re not doing it professionally. A
 hobby isn’t a negative thing, until last December my OSS work was
 entirely a hobby too, and it’s still a hobby in my spare time too.

That use of hobby vs. professional is completely irrelevant to the
discussion, and is effectively condescending and ad hominem.  In my
experience, the quality and committment of a developer's open source work
are often unrelated to whether she gets paid directly by an employer to
do it.  Getting paid *does* make it possible to devote more time, rather
than passion, to one's projects.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlRAPOIACgkQ+gerLs4ltQ5vWACfRDCmT5yjkqfeBB+4xGAiBnAv
n7MAoKag+7GkicRdZ9eSpJdz+HKml6aG
=5Uxr
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Enterprise Python - Multicomponent Projects

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/16/2014 12:57 PM, Jim Fulton wrote:
 On Wed, Apr 16, 2014 at 12:18 PM, Tin Tvrtković tinches...@gmail.com
 wrote:
 Hello packaging community,
 
 I'm investigating ways of setting up Python projects at my
 workplace. We're predominantly a Java shop, but we might be dipping
 our toes in Python waters (finally!) due to a fortuitous project and
 my multi-year insistence, so I'm contemplating how to set up our
 Python build system to minimize workflow differences for other
 developers (well, and myself).
 
 I've actually written uš a lengthy description of Maven and why we
 use it but I'll spare you for now. :) To keep the story short, I'm
 interested in options for setting up a multi-module Python project.
 By 'multi-module' I don't mean a single setuptools-based project
 with several .py files inside, but a way of triggering a complex
 build process with a single command that would build all sub-modules
 (essentially sub-projects) and produce a number of end artifacts -
 just like Maven. Imagine a repository containing 30 separate Django
 apps, packaged independently, 10 utility libraries, 10 Django
 projects combining those app, and 10 RPM building projects for 
 packaging it all up for deployment.
 
 As far as I know, just using setuptools isn't adequate for a
 workflow like this - setuptools deals with the build process
 (testing, packaging, etc) of a single project only. Solutions that
 come to mind are: a hierarchy of Makefiles, shell scripts, or maybe
 Twitter's Pants, which sort of looks like Maven for Python but would
 probably need contributions to do what we want, and looks
 predisposed to building PEX files which, while very interesting, I'm
 not looking to do right now. None of these solutions are really
 ideal, especially if I want to support development on Windows (which
 I absolutely want).
 
 I've even thought about actually using Maven, but that's just a
 Pandora's box of problems waiting to happen.
 
 I'd appreciate insight on this from anyone who's thought about (and
 maybe solved) problems like this. I'm also willing to engage and
 contribute to improving the situation, especially if there's low
 hanging fruit to be picked. How do other companies handle large
 Python repositories with a lot of subcomponents?
 
 Checkout Buildout, http://www.buildout.org
 
 It addresses a lot of the same problems.  Of course, for Python,
 compiling is (mostly) not all that important.  For us (Zope
 Corporation) buildout is more about assembly/deployment, both for
 development and production, that building.

buildout also allow for reproducible builds of things that *do* require
compilation (e.g., via the 'zc.reciple.cmmi' recipe for
'configure-make-make install' software).


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNOwLcACgkQ+gerLs4ltQ46aACgts47yE/ErKtqag0FyOEpfCZP
4pAAoI8d04UodGt3NQB0AzPPJbJITPb/
=vBpI
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Versioned entry points

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/28/2014 01:18 PM, Vinay Sajip wrote:
 Does anyone have any thoughts?
 
 Note that there is one situation where scripts for multiple Python 
 versions reside in the same directory: per-user site-packages (PEP
 370). If you install a package which has scripts and you don't write
 versioned scripts, a second installation of that package (with a
 different Python version) will cause the first script to be
 overwritten. Much of the time this won't matter, but there might be
 scenarios where it does.
 
 It may also give a problem when uninstalling, or when verifying the 
 installation (as the hash of an overwritten script may not match
 what's expected, as per the original installation).
 
 To avoid overwriting, one would need to write versioned scripts
 *only* :-)

Heh, sounds like a call for Underdog^W:

  $ python setup.py altinstall


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM1vkAACgkQ+gerLs4ltQ5CLACgodRwkXiS9irK/nP3dKPnlaXO
5GYAoKbJ4NiDFJdHNIWPozIpMzN6+z62
=q7Bh
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Pycon

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/28/2014 03:06 PM, Daniel Holth wrote:
 Who is going to pycon? I will be there.

I'll be there Tuesday evening through Saturday morning.  I'd love to buy
any fellowship^wPyPA members a beverage-of-choice.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlM10h8ACgkQ+gerLs4ltQ48ewCgsyGo69m2iKAHAUtiC0/43G01
iTgAoKfZAWphPIoQj5Iih/qIJ3Z8hTqR
=ETBo
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] waf can be used to compile Python extension modules

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/21/2014 02:37 PM, Paul Moore wrote:
 Again, though, that's only needed for pip wheel or for the 
 install-direct-from-source cases that may not even be expected to
 work in the new metabuild system...

Hmm, that is a clear case of baby-with-the-bathwater if I ever saw one.
Installing from an sdist has got to be orders-of-magnitude more common
than anything requiring a separate compilation / build step.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMsieIACgkQ+gerLs4ltQ4cTACfbzcmVCMkAcXw8/4IWmNonAZV
hlYAn2iNppd+ICEz7L2qr4sxnIISqykY
=Dzaq
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Hello Greg/Anthony

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/19/2014 10:51 PM, Matt Goodman wrote:
 I have a couple tweaks which makes distutils more functional for the
 mscv family.  Namely exposing the compiler/link flags that are
 necessary for linking against Python without dependence on the full
 msvc import being successful.  There are a bunch of hack-arounds
 oribiting this problem, and I would be willing to do some work to
 smooth it over.
 
 Is there a github repo for this, or is it a part of python core.  In
 short, is there any way I can contribute this code into distutils
 somehow?

distutils is in the core as part of the standard library.  The canonical
repository is at:

  http://hg.python.org/cpython/

Submitters should follow the process outlined in the Python Developers'
Guide:

  http://docs.python.org/devguide/


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMGIbAACgkQ+gerLs4ltQ7cuQCgnfoP8R+jLp5SHncVwbD3+5ac
is0An0YZkVXX017wUEiZ1pP3WpLhul+k
=M+Em
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 3.0b1 available for preview

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/11/2014 11:09 PM, Jason R. Coombs wrote:

 I'm pleased to announce that Setuptools 3.0b1 is now available for 
 download from the project downloads page:
 
 https://bitbucket.org/pypa/setuptools/downloads
 
 This backward-incompatible release contains the changes detailed in
 the CHANGES.txt file:
 
 https://bitbucket.org/pypa/setuptools/src/3.0b1/CHANGES.txt?at=default

  Please give this beta release a try or review the changes for any
 impact this might have on your package. I anticipate most users will
 find these changes of no consequence, but if there are any issues that
 might affect your package that don't have an obvious solution, please
 file a ticket.

I just tested SubstanceD using virtualenv's built with both Python 2.6.9
and Python 3.3.3.  All tests pass, exercising a stack which includes
ZODB, the zope.* packages, pyramid, etc.

I did see one at-exit failure (during the 'setup.py develop' under
2.6.9), but it was harmless AFAICT.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlL7yuwACgkQ+gerLs4ltQ7j8gCfd34nVzU3w/GCVfaxEAzx8jKm
gPsAn0gVS/YikXf64JkSr1L/G3n+aoXR
=s2z/
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] wheels on sys.path clarification (reboot)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2014 06:55 PM, Noah Kantrowitz wrote:

 If you are going to document this, and it is not going to be
 explicitly supported by the spec (it isn't), the _only_ logical thing
 is to document that this is undefined behavior and while it works now,
 people should not depend on it. Under no circumstance should we
 document this as well it works right now without guidance about the
 fact that it isn't part of the spec and is _not_ a candidate for
 future design decisions. If someone would like to propose amending the
 spec that can happen separately, but as it stands right now this is
 nothing but convenient, undefined behavior.

Nick's point in this thread is that zip-importability is a *necessary
corrolary* (not an implementation detaiL) of the no special installers
design choice.

- - Given that there is a non-empty set of wheels which can be unpacked
  to a filesystem-directory tree in a directory on sys.path, and that
  some of those wheels are already known not to otherwise break zip-
  importability, it is a logical necessity that such wheels can be
  put onto sys.path without unpacking.  We already have existence proof
  for this in software being released *by the folks who made these
  specs*.

Noting is as such is the *point* of Nick's change.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLp2hIACgkQ+gerLs4ltQ6VGACgjnYRbgVSs8ceTXNeWTH0zCls
yHwAn0/nyDUMRjNl7ARi0bVtkBOeO1nJ
=2pvt
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 2.0 Released

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/09/2013 04:40 PM, Antoine Pitrou wrote:
 Is there a changelog?

https://bitbucket.org/pypa/setuptools/src/f4d6757ae9fa79df03ef6ed070ab8757707fe963/CHANGES.txt?at=default


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKmPi0ACgkQ+gerLs4ltQ6HggCguPzkufm/VmuORsxC5xJ59rwQ
yY4An2y622rRFmNFrNOxEit1TED0QpMw
=P0Ix
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling the binary dependency management problem

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2013 05:07 PM, Vinay Sajip wrote:
 On Sun, 1/12/13, Paul Moore p.f.mo...@gmail.com wrote:
 
 If the issue is simply around defining compatibility tags that
 better describe the various environments around, then let's just
 get on with that - we're going to have to do it in the end anyway,
 why  temporarily promote an alternative solution just to change our
 recommendation later?
 
 This makes sense to me. We should refine the compatibility tags as
 much as is required. It would be nice if there was some place (on
 PyPI, or elsewhere) where users could request binary distributions for
 specific packages for particular environments, and then some kind
 people with those environments might be able to build those wheels and
 upload them ... a bit like Christoph Gohlke does for Windows.

The issue is combinatorial explosion in the compatibility tag space.
There is basically zero chance that even Linux users (even RedHat users
across RHEL version) would benefit from pre-built binary wheels (as
opposed to packages from their distribution).  Wheels on POSIX allow
caching of the build process for deployment across a known set of hosts:
 they won't insulate you from the need to build in the first place.

Wheels *might* be in play in the for-pay market, where a vendor supports
a limited set platforms, but those solutions will use separate indexes
anyway.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKcizYACgkQ+gerLs4ltQ6kKwCfRa5s8XnM5SwlnnIHGGJ8dJSg
hPUAn1TLWQNxtbQmPvvMPT2rEmlhCwq5
=xRsn
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling the binary dependency management problem

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2013 05:17 PM, Nick Coghlan wrote:

 I see conda as existing at a similar level to apt and yum from a
 packaging point of view, with zc.buildout as a DIY equivalent at that
 level.

FTR: zc.buildout does nothing to insulate you from the need for a
compiler;  it does allow you to create repeatable builds from source for
non-Python components which would otherwise vary with the underlying
platform.  The actual recipes for such components often involve a *lot*
of yak shaving. ;)


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKcjIMACgkQ+gerLs4ltQ5XlQCeMmoyvAOvJGChhpGOF2Phkut0
nfwAnjj2pbr8bHKfS8+lzt/XorPVNzSe
=QmuK
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling the binary dependency management problem

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/01/2013 06:38 PM, Paul Moore wrote:
 I understand that things are different in the Unix world, but to be
 blunt why should Windows users care?

You're kidding, right?  90% or more of the reason for wheels in the first
place is because Windows users can't build their own software from
source.  The amount of effort put in by non-Windows package owners to
support them dwarfs whatever is bothering you here.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKcjTgACgkQ+gerLs4ltQ7fQQCg0Pfd5tp3vvEsJnJ0aNLNeIXH
bVwAn2av6wxVMXEqe4jIQLL+2W4oqQ9G
=foOx
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Handling the binary dependency management problem

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/02/2013 12:23 PM, Vinay Sajip wrote:
 On Mon, 2/12/13, Tres Seaver tsea...@palladion.com wrote:
 
 The issue is combinatorial explosion in the compatibility  tag
 space. There is basically zero chance that even Linux users (even
 RedHat users  across RHEL version) would benefit from pre-built
 binary wheels (as  opposed to packages from their distribution).
 Wheels on POSIX allow caching of the build process for deployment
 across a known set of hosts: they won't insulate you from the need
 to build in the first place.
 

 The combinations are number of Python X.Y versions x the no. of
 platform architectures/ABI variants, or do you mean something more
 than this?

Trying to mark up wheels so that they can be safely shared with unknown
POSIXy systems seems like a halting problem, to me:  the chance I can
build a wheel on my machine that you can use on yours (the only reason to
distribute a wheel, rather than the sdist, in the first place) drops off
sharply as wheel's binariness comes into play.  I'm arguing that wheel
is not an interesting *distribution* format for POSIX systems (at least,
for non-Mac ones).  It could still play out in *deployment* scenarios (as
you note below).

Note that wheel's main deployment advantage over a binary egg
(installable by pip) is exactly reversed if you use 'easy_install' or
'zc.buildout'.  Otherwise, in a controlled deployment, they are pretty
much equivalent.

 The wheel format is supposed to be a cross-platform binary package 
 format; are you saying it is completely useless for POSIX except as a 
 cache for identical hosts? What about for the cases like simple C 
 extensions which have no external dependencies, but are only for 
 speedups?

I have a lot of packages on PyPI which have such optimization-only
speeedups.  The time difference to build such extensions is trivial
(e.g., for zope.interface, ~1 second on my old slow laptop, versus 0.4
seconds without the extension).

Even for lxml (Daniel's original motivating case), the difference is ~45
seconds to build from source vs. 1 second to install a wheel (or and
egg).  The instant I have to think about whether the binary form might be
subtly incompatbile, that 1 second *loses* to the 45 seconds I spend over
here arguing with you guys while it builds again from source. :)

 What about POSIX environments where compilers aren't available (e.g.
 restricted/embedded environments, or due to security policies)?

Such environments are almost certainly driven by development teams who
can build wheels specifically for deployment to them (assuming the
policies allow anything other than distro-package-managed software).
This is still really a cache the build optimization to known platforms
(w/ all binary dependencies the same), rather than distribution.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKcyPsACgkQ+gerLs4ltQ4oBwCgvhoq8ovEn/Bl/0FpBEfI48JY
znEAoJElD+R9SPnJXduwjCy7oxWRmcWH
=a0TT
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/31/2013 02:24 PM, Donald Stufft wrote:
 To be honest the same problems likely exists on Windows, it?s just
 less likely and the benefits of prebuilt binaries greater.

For all platforms *except* Windows, wheels are essentially caches --
there is no real reason to distribute them via PyPI at all, because OSx
and Linux develpoers will have tools to build them from sdists.

Pip *does* need to allow installing them on those platforms, but probably
only via explicit paths / URLS (rather than finding them on PyPI).


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJywmwACgkQ+gerLs4ltQ5P/ACfXcMJj4dmnlNJEccZ8gxi8FLR
GrQAoLxxgeVnKRvuoscR6GuabwGxfsnF
=gZW1
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/31/2013 05:52 PM, Eric V. Smith wrote:
 I'm more than happy to build them myself on a dedicated build
 machine.

Right -- that makes them back into caches. ;)  You can safely deploy them
because you know the architecture / libc / etc. against which you built
them.  They are highly unlikely to be useful to anyone *else*, however,
except by accident.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJy1vwACgkQ+gerLs4ltQ7HqQCgs3toEwtRSn5q+USRXdOWDB+C
dusAn0fSfRyUmRSvqGQ3IUh1Kl6Jh36X
=OCEp
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/31/2013 04:55 PM, Donald Stufft wrote:
 
 On Oct 31, 2013, at 4:49 PM, Tres Seaver tsea...@palladion.com
 wrote:
 
 Pip *does* need to allow installing them on those platforms, but
 probably only via explicit paths / URLS (rather than finding them on
 PyPI).
 
 You can install them just fine on any platform, the only restrictions
 are PyPI won?t let you upload them, and pip won?t try to install them
 from pypi.python.org.

Excellent -- sorry I misunderstood.  AFAICT, you could leave that
restriction in place for ever for Linux.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJy10kACgkQ+gerLs4ltQ5C0QCePWr4hX6zTff9hyCO9+w5s0Ac
R8sAn11NPAr3d+SCpricLcdLOhtk/nmp
=V/rv
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] URL Structure of Packages URLs

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/08/2013 09:19 AM, Donald Stufft wrote:
 I was wondering if anyone was aware of anything that relies on the
 current structure of package urls, namely:
 
 /packages/source|any|etc/D/Django-1.0.tar.gz?
 
 I would like to change this but before I work up a concrete plan for 
 people to comment on and discuss I'm trying to figure out what, if 
 anything, depends on that current structure.

Any such change should leave behind rewrite rules which 301 to the new,
blest URLs.  #dontbreaktheweb and all that.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJVpfAACgkQ+gerLs4ltQ6rhwCffZISAc+VDiqX5NQ/3ET9inJp
daAAmgNsHb/0vIVjSTMLrxEGT9S4yodT
=2TOU
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Deviation between distutils and setuptools over package_data

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/20/2013 09:11 AM, Sebastien Douche wrote:
 On Fri, Sep 20, 2013 at 2:15 PM, Jim Fulton j...@zope.com wrote:
 Did setuptools recently learn about git?
 
 Nop.

I use setuptools-git regularly without problems.


 I would love an option to ignore VCS and let me specify what I want
 *explicitly*.
 
 Or remove the handling of VCS?

- -1.  I haven't yet tried Marius' tool, but manually maintaining
MANIFEST.in is an unaceptable bug magnet.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlI8WLwACgkQ+gerLs4ltQ4SIgCgh2dRMexciWxnaJBFrU700PDl
dOkAoNUNELNFj9Ee0T+mD6ajC3FvQ8xV
=FAe6
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Multi-version import support for wheel files

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 08/27/2013 05:00 AM, Nick Coghlan wrote:

 PJE and Jason were probably the only other current distutils-sig
 participants familiar enough with setuptools and pkg_resources to
 understand the distinction between that aspect, the default version
 handling and the activation API

There are lots of folks here who have been building tooling on top of
eggs for almost a decade now.  Perhaps those who *do* grok how that stuff
works (I'd be willing to guess a lot more than the three of you and
myself) weren't alarmed by you proposal.  Oophobia is not ubiquitous. :)



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlIcxDEACgkQ+gerLs4ltQ4qCgCfQKtjEAQkx7XnkQS8A8Q767E6
lnwAoNJAcSDTbN6I1DW2DZAzC3lMvolQ
=AeYU
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] a plea for backward-compatibility / smooth transitions

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/29/2013 10:51 AM, Donald Stufft wrote:
 I've personally gotten or seen more complaints over the naming of a
 variable in the config file then I have over any changes we've made.
 The runner up to that is the fallout from switching to requiring
 verified SSL.

The past few months have generated a *lot* of teeth-gnashing /
hair-pulling, especially among downstream developers (those unlikely to
be reading this SIG):

- - HTTPS-only PyPY

- - Distribute / setuptools merge, e.g. cratering folks who use a
  distro-managed 'python-distribute' package.

- - Pip's new backward-imcompatible final releases by default.

I think we are going to be in a much better place for all that, but let's
not deny the pain involved for *everybody* in getting there.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlH2n+EACgkQ+gerLs4ltQ6megCeN8V8IN4OT6rWfZg1tw1GtUaO
2jwAoLRXzLyjjMbiLrcfqLG0Ge1NQnMq
=7ufm
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Shebang lines, /usr/bin/python, and PEP394

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/26/2013 03:32 PM, Barry Warsaw wrote:
 If you're installing a script into a virtualenv, it's better to
 rewrite the shebang to use the executable that was used to install 
 it.

Exactly -- the script likely won't run at all outside the environment
where its dependencies are installed.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHy4E0ACgkQ+gerLs4ltQ57XgCg1JsuCk2zxOpJyWNoHv1V/0h/
Y1EAoND2clmyfdHjqVY/3p+PafWXM0Lp
=uzfB
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Best practices for optional C extensions

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/13/2013 09:14 AM, Ben Darnell wrote:
 I'd like to add a C extension to speed up a small bit of code in a
 package (Tornado), but make it optional both for compatibility with
 non-cpython implementations and for ease of installation on systems
 without a C compiler available.  Ideally any user who runs pip
 install tornado on a system capable of compiling extensions would get
 the extensions; if this capability cannot be detected automatically
 I'd prefer the opt-out case to be the one that requires non-default
 arguments.  Are there any packages that provide a good example to
 follow for this?
 
 PEP 426 uses c-accelerators as an example of an extra, but it's
 unclear how this would work (based on the equivalent setuptools
 feature).  There doesn't appear to be a way to know what extras are
 requested at build time. If the extra required a package like cython
 then you could build the extension whenever that package is present,
 but what about hand-written extensions?  Extras are also opt-in
 instead of opt-out, so I'd have to recommend that most people use pip
 install tornado[fast] instead of pip install tornado (with
 tornado[slow] available as an option for limited environments).

zope.interface subclasses the 'build_ext' command so:


-  % -
from distutils.command.build_ext import build_ext
from distutils.errors import CCompilerError
from distutils.errors import DistutilsExecError
from distutils.errors import DistutilsPlatformError


class optional_build_ext(build_ext):
Allow the building of C extensions to fail.

def run(self):
try:
build_ext.run(self)
except DistutilsPlatformError as e:
self._unavailable(e)

def build_extension(self, ext):
try:
build_ext.build_extension(self, ext)
except (CCompilerError, DistutilsExecError) as e:
self._unavailable(e)

def _unavailable(self, e):
print('*' * 80)
print(WARNING:

An optional code optimization (C extension) could not be compiled.

Optimizations for this package will not be available!)
print()
print(e)
print('*' * 80)
-  % -



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHitjoACgkQ+gerLs4ltQ7SJQCgrhgN58g9ztFPEkFAOM49Wu4p
RpQAoLnboKietjTx3eXho1kyRvH3r2uN
=qWRK
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Current status of PEP 439 (pip boostrapping)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/13/2013 08:25 AM, Nick Coghlan wrote:
 I think we need to flip the dependencies so that pip as the installer
 has all the essential code for installation from PyPI and then
 setuptools and distlib depend on that pip infrastructure. No need to
 add anything to the standard library prematurely when we can add it to
 pip instead.

- -1.  That would effectively mean inlining the bulk of setuptools' code
into pip (which is just a UI / policy shim over it).  You might as well
just have your bootstrapper install both pip and setuptools and be done

Unless distlib (or something like it) lands in the stdlib with enough
features to support a setuptools-less pip, of course.

At-which-point-the-State-will-wither-away'ly,


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHhbLkACgkQ+gerLs4ltQ51fQCfZrmZN5mJKrtoGFTk0YqQrBHd
F/IAnRp6XjoU4SpXZ4v3Uz6iOBrCZZZn
=gSA5
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout/setuptools/distribute unhelpful error message (0.7.x issue?)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/07/2013 03:08 AM, Chris Withers wrote:
 
 I don't see any distribute in there, and I don't know where it might
 be...

'pkg_resources' (/usr/lib/python2.6/dist-packages/pkg_resources.py) comes
from either setuptools or distribute -- in your case, distribute
(probably via a 'python-distribute' Debian package, given that path).

Either you need to get that system pacakge updated, or else removed, or
else insulate yourself from it (e.g., with a 'virtualenv --no-setuptools'
or a self-built Python).


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHZbdIACgkQ+gerLs4ltQ7y1ACfSuEQBXY/THSNDsoLysgORTQv
HeQAoI5TH6WOqNG3TR9Fuu4VKURpeil2
=kkLS
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/2013 12:22 PM, Jason R. Coombs wrote:
 Additionally, I released Distribute 0.7 to PyPI. This means that users
 who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply
 invoking `easy_install -U distribute` (or `easy_install
 distribute=0.7`). Windows users should use `easy_install-script -U
 distribute` (to avoid file in use errors on easy_install.exe).

Jason, the cheeseshop doesn't show a distribute 0.7 release.  We have
folks who can't easily test the new version of zc.buildout because they
are stuck on a setuptools-denying version of distribute.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHIfl8ACgkQ+gerLs4ltQ7PaQCgruExzWYv6I9qw6LQSx5RwnzH
hPQAoI1Ta2lImcTdgHzq52U3N2eKv5o3
=kyNO
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/24/2013 04:44 PM, Jason R. Coombs wrote:
 I had to pull distribute 0.7 because older versions of pip couldn't
 handle the upgrade.

You mean 'pip install -U distribute' fails with distribute 0.7?  This
works for me in a brand-new virtualenv w/ distribute:

  $ bin/pip install \
 --find-links=https://bitbucket.org/pypa/setuptools/downloads/ \
 -U distribute

 I'll be re-adding distribute 0.7 back to PyPI following the new 
 release of pip. Can you test by pointing to the bitbucket downloads in
 the short term?
 
 Can you tell me about what issues the buildout users are experiencing?
 Are they trying to upgrade a buildout from distribute to setuptools?
 Or is there an issue with creating new buildouts against the latest
 setuptools?

No issue with the latest setuptools. The prevent setuptools installation
at all costs behavior of distribute 0.6.x kills the buildout (or its
bootstrap) which tries to install setuptools 0.7.2.  If there was a clean
way to upgrade from distribute 0.6 before running the bootstrap, that
would be enough:  but then, that was what distribute 0.7 was supposed to
do. :(

 I'm hesitant to release Distribute 0.7 because even the latest version
 will break the 'easy_install' scripts for users who upgrade via pip.
 Actually, on second thought, pip users might consider that a feature.

pip users can't spell easy_install, so you should be safe. :)

 If there's going to be a re-release of distribute 0.7, it'll need to
 be coordinated with the pip and virtualenv releases, which we're
 planning for the weekend after next (Jul 6). I know that's a long
 time, but I'm hoping there's a suitable workaround for buildout. If
 not, then getting an updated distribute (and possibly pip) out sooner
 (even without immediate) virtualenv support might be possible.

Where are the problems pip users reported with distribute 0.7 archived?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlHItfQACgkQ+gerLs4ltQ5PWQCdHenszGzMEbOXgzmHyIKK/EwW
X4oAnRE7uAYmBQE97gabYiWFbjRA1Egz
=/k4B
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] error using easy_install

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/15/2013 02:29 AM, Ethan Furman wrote:
 My setup.py:
 
 -- 8 -- 
 from distutils.core import setup
 
 long_desc = open('enum.rst').read()
 
 setup( name='stoneleaf.enum', version='1.0.1', 
 url='https://pypi.python.org/pypi/stoneleaf.enum', packages=['enum'], 
 package_dir={'enum':''}, package_data={'enum':['enum.rst', 'enum.pdf',
 'test/test_enum.py', 'test/py2_test_enum.py',
 'test/py3_test_enum.py']}, license='BSD License', description='Python
 3.4 Enum backported to 3.3, 3.2, 3.1, 2.7, 2.6, 2.5, and 2.4', 
 long_description=long_desc, provides=['enum'], author='Ethan Furman', 
 author_email='et...@stoneleaf.us', classifiers=[ 'Development Status
 :: 5 - Production/Stable', 'Intended Audience :: Developers', 'License
 :: OSI Approved :: BSD License', 'Programming Language :: Python', 
 'Topic :: Software Development' ], ) -- 8
 --
 
 Error trying to install it with easy_install after uploading it to
 PyPI:
 
 ethan@hydra:~$ sudo easy_install stoneleaf.enum Searching for
 stoneleaf.enum Reading http://pypi.python.org/simple/stoneleaf.enum/ 
 Best match: stoneleaf.enum 1.0.1 Downloading 
 http://pypi.python.org/packages/source/s/stoneleaf.enum/stoneleaf.enum-1.0.1.zip#md5=c41abd7ad04f11e8b545cfca7758a4f2

 
Processing stoneleaf.enum-1.0.1.zip
 Writing /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/setup.cfg 
 Running stoneleaf.enum-1.0.1/setup.py -q bdist_egg --dist-dir 
 /tmp/easy_install-LY_zzX/stoneleaf.enum-1.0.1/egg-dist-tmp-IpvhLD 
 error: Setup script exited with error: can't copy 'num.rst': doesn't
 exist or not a regular file
 
 
 There is no 'num.rst' file in the package -- it should be 'enum.rst'.
 
 Any ideas?  Is this the right place to post?

This is the right place.  Your 'package_data' declaration is getting munged::

  /tmp/stone/stoneleaf.enum-1.0.1/build/bdist.linux-i686/egg/setuptools
/command/build_py.py(80)build_package_data()
 - self.copy_file(os.path.join(src_dir, filename), target)
 (Pdb) l
  75lastdir = None
  76for package, src_dir, build_dir, filenames in self.data_files:
  77for filename in filenames:
  78target = os.path.join(build_dir, filename)
  79self.mkpath(os.path.dirname(target))
  80  -self.copy_file(os.path.join(src_dir, filename),
target)
  81
  82
  83def analyze_manifest(self):
  84self.manifest_files = mf = {}
  85if not self.distribution.include_package_data:
 (Pdb) pp self.data_files
 [('enum',
   '',
   'build/lib/enum',
   ['num.rst',
'num.pdf',
'est/test_enum.py',
'est/py2_test_enum.py',
'est/py3_test_enum.py'])]

Looking at the 'build_py' step, this line is problematic:

   package_dir={'enum':''},

When I change it to:

   package_dir={'enum':'.'},

then the install succeeds.  I would probably just make an 'enum' subdir,
move the files into it, and be done with it ('setup.py' isn't logically
part of the package:  it is in the wrapper).



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG8oNUACgkQ+gerLs4ltQ4axQCgh1YAyvqC/ZRJs1V6U4jQ66as
9VQAnRmJqhFINjzjCx2eftJfALKj/vsc
=o/a+
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Post-merge setuptools Python 3 single-codebase port available

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/15/2013 12:35 PM, Vinay Sajip wrote:
 Following the setuptools/distribute merge, I've updated my single
 codebase port of the merged setuptools at [1]. Source of my repo is
 available at [2] (single-codebase branch). Travis integration has been
 set up; results are at [3].
 
 Currently, all tests are passing for 2.5, 2.6, 2.7, 3.2, and 3.3.
 
 For installation into PEP 405 venvs, a wheel has been set up at [4].
 
 Feedback welcome.

Thank you for your work!  +100 for an immediate merge.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG8oTgACgkQ+gerLs4ltQ5/FwCgiYZt/q+t6t2emibspuUAYDLG
r4UAn07mxKKQWvpNhG1aLgLZsZ2i2WIO
=/7Yf
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/11/2013 05:27 AM, Chris Withers wrote:
 On 10/06/2013 18:57, Tres Seaver wrote:
 Works for me:
 
 $ mkdir /tmp/withers $ cd /tmp/withers $ echo [buildout] parts =
 buildout.cfg $ wget http://downloads.buildout.org/1/bootstrap.py 
 ... $ /opt/Python-2.5.x/bin/python bootstrap.py
 
 Try with 2.7, and also try going from 1 to 2 and back again by
 switching bootstraps.
 
 There's likely something funky going on (.installed.cfg, develop-eggs
 or some other goat sacrifice in bin/) but it definitely happened.

That same recipe works with 2.7.  In general, the presence of
.installed.cfg should be thought of as problematic for any big surgery
(like changing bootstraps, or major versions of buildout), because it
hampers repeatability in order to make the build run faster.

When in doubt, remove .installed.cfg and re-run buildout after any such
change.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG3sSMACgkQ+gerLs4ltQ4ExACfaXdJ1n3jFV+W0HmuNuKB1SDN
8W0Anj3WVTQebSJ71K1Q488KCr5JK/gd
=NsB8
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout 1 still not managing to pin buildout to 1.x

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/10/2013 06:22 AM, Chris Withers wrote:
 Hi All,
 
 So, having given up on buildout 2 for this package again (need for 2.5
  support) I dutifully put in the bootstrap.py from buildout 1:
 
 curl http://downloads.buildout.org/1/bootstrap.py  bootstrap.py
 
 python2.5 on my mac didn't work, thanks to a broken system python, so
 on to 2.6, which appeared to go okay except:
 
 buzzkill:checker chris$ bin/nosetests zc.buildout 2 needs distribute,
 not setuptools.  Are you using an outdated bootstrap.py?  Make sure
 you have the latest version downloaded from
 http://downloads.buildout.org/2/bootstrap.py
 
 Great... Wonderful... I thought 1/bootstrap.py was supposed to pin to
  buildout 1 for you without the need for any other voodoo?


Works for me:

 $ mkdir /tmp/withers
 $ cd /tmp/withers
 $ echo [buildout]
 parts =  buildout.cfg
 $ wget http://downloads.buildout.org/1/bootstrap.py
 ...
 $ /opt/Python-2.5.x/bin/python bootstrap.py
 Downloading http://pypi.python.org/packages/2.5/s/setuptools/setuptools-\
0.6c11-py2.5.egg
 Creating directory '/tmp/withers/bin'.
 Creating directory '/tmp/withers/parts'.
 Creating directory '/tmp/withers/eggs'.
 Creating directory '/tmp/withers/develop-eggs'.
 Getting distribution for 'setuptools'.
 /opt/Python-2.5.5/lib/python2.5/distutils/dist.py:263: \
UserWarning: Unknown distribution option: 'src_root'
 warnings.warn(msg)
 Got setuptools 0.7.2.
 Generated script '/tmp/withers/bin/buildout'.
 $ bin/buildout
 $ ls eggs
 setuptools-0.7.2-py2.5.egg  zc.buildout-1.7.1-py2.5.eg



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG2E3oACgkQ+gerLs4ltQ4n0ACgnIJb6c4Wf/3i+sY57FY1BRGa
emgAoJdTohJwbWmhGCvhzt/Pbv9AJTGT
=Bn58
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/2013 12:22 PM, Jason R. Coombs wrote:
 On behalf of the PYPA, I'm excited to announce that Setuptools 0.7 is
 now official and complete.
 
 Released to PyPI, Setuptools 0.7.2 is now available for all to see by 
 default (https://pypi.python.org/pypi/setuptools/). Users of
 Setuptools 0.6 may upgrade by simply running `easy_install -U
 setuptools`.
 
 Additionally, I released Distribute 0.7 to PyPI. This means that users
 who have Distribute 0.6.x can upgrade to setuptools 0.7 by simply
 invoking `easy_install -U distribute` (or `easy_install
 distribute=0.7`). Windows users should use `easy_install-script -U
 distribute` (to avoid file in use errors on easy_install.exe).
 
 The documentation for Setuptools 0.7.2 has been uploaded to 
 https://pythonhosted.org/setuptools and includes the notes about the
 merge in addition to the official documentation.
 
 Please report any issues at the project page 
 (https://bitbucket.org/pypa/setuptools).


Thanks for all the work that went into this release.  I'm working to get
buildout 2.0 to use the new setuptools, and need to encode a more-or-less
permalink URL for 'ez_setup.py' -- do we not have a better URL for it
than the Bitbucket 'raw' source?



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG0t74ACgkQ+gerLs4ltQ6Q5wCg2hMoLBxfv6NIR/DTOUjdBNei
kVUAnjZ9ua2gRpwXyeRw/i1CIBPeV9e0
=Ksc7
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/2013 01:49 PM, Jason R. Coombs wrote:
 Is the bitbucket 'raw' source not suitable? It uses the version tag to
  indicate precisely which file is appropriate, which means we don't
 have to redundantly host that file elsewhere.
 
 Oh, I think I see - there's no link that doesn't change - you want a
 permalink for the latest stable release. I hadn't considered that use
 case, but you're right - we do want that. Perhaps the file could be
 added to pythonhosted.org alongside the documentation. Or maybe it
 belongs on bitbucket in `downloads`.
 
 I need to figure out which is more straightforward w.r.t.
 authentication. The distribute process was messy because it involved
 SSH and keys that had to be manually managed.
 
 I'm leaning toward uploading it to BitBucket downloads as part of the
 release script.
 
 I'll put ez_setup.py for 0.7.2 in downloads for now. You can assume
 that's where the permalink will be.
 
 If anyone has a better suggestion, please raise it.

I would prefer a URL on a host managed by the Python infrastructure team:
 either PyPI or the pythonhosted org.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG1B2sACgkQ+gerLs4ltQ7H8gCdE/g1UBfr74s7v5tmuHLXdktx
3L0AoMxPG48F5KM8Ae+v5A1g9nU2B4To
=pTON
-END PGP SIGNATURE-
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7.2 and Distribute 0.7 (compatibility wrapper) on PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/09/2013 10:28 PM, Donald Stufft wrote:
 
 On Jun 9, 2013, at 9:51 PM, Nick Coghlan ncogh...@gmail.com wrote:
 
 On 10 June 2013 03:49, Jason R. Coombs jar...@jaraco.com wrote:
 I'm leaning toward uploading it to BitBucket downloads as part of
 the release script.
 
 I'll put ez_setup.py for 0.7.2 in downloads for now. You can
 assume that's where the permalink will be.
 
 I think that's a good way to publish it securely to the PSF 
 infrastructure team (at least for now)
 
 If anyone has a better suggestion, please raise it.
 
 As others have suggested, we should work with Donald and Noah to
 get the bootstrapping script an official home somewhere on 
 pypi.python.org.
 
 If you want it under pypi.python.org it'll probably need manually
 sent to myself for the time being. I believe it could easily be hosted
 via python hosted.org though without needing manual intervention.

I'm not wedded to anyplace in particular.  Having the bootstrap needed to
make effective use of PyPI hosted on PyPI itself makes a lot of sense to
me.  Maybe under a URL like this one?

  https://pypi.python.org/bootstraps/ez_setup.py

The main key is that the URL should be immutable (so we can doucment it
widely, and use it in scripts) and have availability as good as the
cheeseshop (I'm not knocking Bitbucket in particular).

If the file were copied into the Sphinx docs uploaded to
pythonhosted.org, that would probably work just as well.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlG1PO8ACgkQ+gerLs4ltQ64WQCeO0tVhPBjlmzvtzdBx0C4V5Hr
lVAAniVJ4XuAnPfV7NXT7KvcextrrTaJ
=ILKd
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Preemptive Apology for Volume of Mail

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/2013 01:46 AM, Donald Stufft wrote:
 Just want to apologize to anyone who recently received a lot of mail 
 from me.
 
 I realized shortly after I queued all the emails that they should
 have been grouped by user and not by package.
 
 So, I'm sorry. I really am and I feel bad about the amount of mail
 some of you have received from me.

I don't mind the 250 or so messages, but I'd *really* like to get a bulk
change UI to set all 250 to #1 at once -- there is no way I'm going to
take the time to clickety-click through them and fix them by hand.
Without such a UI, I guess I'm just going to wait for the auto-conversion.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGuA6UACgkQ+gerLs4ltQ5CuACeMst3VewOCkGMx82Dx62PTtan
Bj0AnRpSCCymJGMdxjuVx0/klKqIYxfo
=IELQ
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Preemptive Apology for Volume of Mail

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/04/2013 11:13 AM, Donald Stufft wrote:
 I'll see what I can whip up. Would a script be ok?

Sure -- I'm fine with whatever works.  Thanks!


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGuBUMACgkQ+gerLs4ltQ4+QACeKSfBL2qVzMtphRX+JZ3cmNPQ
0XcAniXUgAIlLaH729gO3GItgUzD0kMW
=NVwu
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7 final available for download

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/02/2013 11:42 AM, Jason R. Coombs wrote:
 I'm pleased to announce the official release of Setuptools 0.7, now 
 available for download from the project page 
 https://bitbucket.org/pypa/setuptools .
 
 
 
 Nothing has changed from the 0.7b4 pre-release. This is the version
 that will be uploaded to PyPI after we work out the technique to
 deploy to PyPI without interfering with the setuptools 0.6 releases.
 
 
 
 For convenience, I've also added experimental .msi installers for
 Windows for Python 3.3 and Python 2.7. Work may continue on these in
 the future, but as the documentation states, the recommended
 installation procedure is to use ez_setup.py.
 
 
 
 To install this latest release, follow the canonical install
 instructions (using ez_setup.py), but direct the script to use
 bitbucket instead of PyPI:

Maybe I'm missing something, but where is the 'ez_zetup.py' script
hosted?  It isn't present in the bitbucket downloads directlry.

  https://bitbucket.org/pypa/setuptools/downloads/

Maybe linking to or recapitulating the canonical install instructions
here would help diespel confusion.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGsj78ACgkQ+gerLs4ltQ4JqQCgrSWCnecjtDTk5BrupmQEEUkB
l/YAn3qY9uxe1Fb4PXPpOnIV0wgWy4Rd
=/7uv
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7 final available for download

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/03/2013 08:44 AM, Tres Seaver wrote:
 On 06/02/2013 11:42 AM, Jason R. Coombs wrote:
 I'm pleased to announce the official release of Setuptools 0.7, now
  available for download from the project page 
 https://bitbucket.org/pypa/setuptools .
 
 
 
 Nothing has changed from the 0.7b4 pre-release. This is the version 
 that will be uploaded to PyPI after we work out the technique to 
 deploy to PyPI without interfering with the setuptools 0.6
 releases.
 
 
 
 For convenience, I've also added experimental .msi installers for 
 Windows for Python 3.3 and Python 2.7. Work may continue on these
 in the future, but as the documentation states, the recommended 
 installation procedure is to use ez_setup.py.
 
 
 
 To install this latest release, follow the canonical install 
 instructions (using ez_setup.py), but direct the script to use 
 bitbucket instead of PyPI:
 
 Maybe I'm missing something, but where is the 'ez_zetup.py' script 
 hosted?  It isn't present in the bitbucket downloads directlry.
 
 https://bitbucket.org/pypa/setuptools/downloads/
 
 Maybe linking to or recapitulating the canonical install
 instructions here would help diespel confusion.

I tried looking at the README on Bitbucket:

 https://bitbucket.org/pypa/setuptools/#rst-header-installation-instructions

but that points to an invalid URL for 'ez_setup.py':

 https://bitbucket.org/pypa/setuptools/raw/0.7.1/ez_setup.py

The version here:

  https://bitbucket.org/pypa/setuptools/raw/0.7/ez_setup.py

points to PyPI for the DEFAULT_URL.  During the beta, I think we need to
have a version ov 'ez_setup.py' available which points to the Bitbucket
download page, rather than PyPI.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGskRMACgkQ+gerLs4ltQ45IQCdEFrOuCszGKStzKxKPdN2vPd/
/fMAn2j5mdBhE4PthXlG/wVVqv1ztoz9
=kFhy
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7 final available for download

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/03/2013 09:04 AM, Christian Heimes wrote:
 It's here https://bitbucket.org/pypa/setuptools/src .

That version points to PyPI as the location, and wants to install version
0.7.1.  Until 0.7 is pushed to PyPI, we need an ez_setup.py available
which points to the bitbucket download page.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGslpwACgkQ+gerLs4ltQ7IRwCfS1suMO0YzA9P1iTvNDDd+Hrm
myoAn0uqw7cyOuqqaHj/DaXO5sRA53BY
=rFuY
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools 0.7 final available for download

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/03/2013 09:14 AM, Tres Seaver wrote:
 Until 0.7 is pushed to PyPI, we need an ez_setup.py available which
 points to the bitbucket download page.

As an alternative, we could just go ahead and push out this version to
the cheeseshop:  AFAICT, it doesn't break stuff (especially compared to
the current 0.6 nightly -- see issue #8[1]), and anybody who needs to can
pin 'setuptools0.7dev'.


[1] https://bitbucket.org/pypa/setuptools/issue/8/


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGsqDAACgkQ+gerLs4ltQ5LHQCdHrCQf4rtvumUvROUJLihdEXC
YvEAn3MIY3o2YYxm+X42santI6fTtXC+
=hsyB
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [issue150] ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat'

[Tres Seaver]

New submission from Tres Seaver:

That Hg commit reference dropped the import of 're', which breaks the 
'_dnsname_to_pat' fallback function.

I reported this on bitbucket:

  https://bitbucket.org/pypa/setuptools/issue/8

and pushed changes for a pull request there:

  https://bitbucket.org/pypa/setuptools/pull-request/4

but Jason thinks the 0.6 branch is still primarily managed here and in SVN.

The bug breaks the zope.org buildouts, which are still using the 0.6 nightlies 
while the 0.7 release waits in the wings.

--
assignedto: pje
messages: 721
nosy: pje, tseaver
priority: urgent
status: unread
title: ssl_support.py: 1868:04732ee16e7e broke '_dnsname_to_pat'

___
Setuptools tracker setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue150
___
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Sooner or later, we're going to have to be more formal about how we name packages.

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/02/2013 03:10 AM, holger krekel wrote:
 Somewhat proper import namespacing is only available with very recent
 python versions which still have a long way to become mainstream.

I don't understand this claim at all.  W'eve had packages in python for
fifteen years, and extensible namespace-package support in one form or
another for eight.  The fact that the Python 3.3 adds support for a new
spelling doesn't mean they are a new feature.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGrhjEACgkQ+gerLs4ltQ7jnQCfYokgj1vHL/pcun2PYmsP6EYD
ei4AoJ0AhzbIckRY+mGtIk89qXqaFjY9
=Mqzk
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] A process for removal of PyPi entries

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/31/2013 06:41 PM, Jim Fulton wrote:
 I hope no one is proposing removing a project simply because someone
 hasn't released a new (after initial) release in some period of time.

Certainly not I:  I'd just like to prevent squatters (no matter how
well-intentioned, Withers!) from tying up a project name indefinitely.
Code talks, as it were:  release something or take your marbles and go home.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGqky0ACgkQ+gerLs4ltQ74iwCgqSr4TqKC/ktgU0XlsDKedp2i
3ZwAnRnuuEX2imZlVs2CT54faUZFYo6l
=qReS
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] A process for removal of PyPi entries

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/31/2013 09:18 AM, Lennart Regebro wrote:
 I'd be OK with after six months automatically removing packages that 
 has only one owner/maintainer, and that owner/maintainer has no other 
 packages, and the package has no available downloads, and no contact 
 information on either package nor registered user.

Why all the extras:  if somebody wants to claim a project name, but can't
upload a release for six months, they should just lose.  I would actually
be willing to have that cut down to a day:  trying to grab the name
before registering / uploading a release should result in loss of the claim.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGpCWIACgkQ+gerLs4ltQ6e5wCbBm6t1T8a5ffPGBEFV0K3s3Fg
jA8AoLVfTLCrSy6aCAbogcEouQc8H8Ak
=bZTd
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Announcing Setuptools 0.7b3

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/25/2013 04:40 PM, Jason R. Coombs wrote:
 Setuptools and Distribute are now merged, and the new home can be
 found at https://bitbucket.org/pypa/setuptools.
 
 Issues for Distribute are still being maintained at its old home, but 
 releases are now made from the 'distribute' fork on the setuptools
 repo. Future releases of Distribute (if any) will be maintenance
 only.
 
 The new setuptools, which is designed to be largely compatible both
 with Distribute and Setuptools can now be downloaded on the
 'downloads' page of the PyPA site:
 
 https://bitbucket.org/pypa/setuptools/downloads
 
 For those familiar with setuptools/distribute, the upgrade process is
 pretty straightforward: remove your old versions of distribute and/or
 setuptools and install the latest. To install the latest, extract the
 .tar.gz, and run setup.py in the target environment. Windows .msi
 installers have been provided as well. Ez_setup.py will not yet work
 until the official release is made to PyPI.
 
 I encourage all of those with experience or interest in packaging to
 try out the new setuptools in your environments. Test it against your
 tool chain. Provide feedback and file issues in the project site.
 
 This limited public release is provided as an advance release prior to
 the full public release. Assuming there are no reported blocking
 issues, a final 0.7 release will be made to PyPI in the coming weeks.

Congratulations, and thanks to the PyPA developers for coming together to
produce this unified release.

FWIW, I was just able to update a setuptools 0.6 virtualenv via:

  $ bin/easy_install -U
https://bitbucket.org/pypa/setuptools/downloads/setuptools-0.7b3.tar.gz

For a distribute-based virtualenv, I had to delete the 'distribute' entry
in 'site-pacakges' after running the 'easy_install' command.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGhPPYACgkQ+gerLs4ltQ5zngCg1iTC2xwLcvZT/MHSi8bNlFDl
clgAnjXOCbXqN0rW1ihwWEBUCFzEFC5U
=MF9s
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 438 - Transition Phase 1

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/18/2013 08:50 PM, Donald Stufft wrote:
 Phase 1 of PEP 438 (http://www.python.org/dev/peps/pep-0438/) has
 begun.
 
 Deployed to production PyPI is: - New packages default to
 pypi-explicit - Old packages default to pypi-scrape-crawl - Package
 Maintainers can select which hosting mode to use - Package Maintainers
 can control what urls show up on their /simple/ index
 
 What's still happening:
 
 - All existing packages will be processed to determine if they host
 files on PyPI, if they host files externally but link directly, or if
 they Host files externally and require scraping the home or download
 url pages. - Taking the data obtained from processing email users to
 tell them if their package can be moved to a more restrictive download
 option (e.g. all their versions are installable directly from PyPI, or
 from a direct link from PyPI). - A Month after that actually moving
 them to their detected new hosting mode (if possible on a per project
 basis).

I would be glad to update all my packages to explicit mode, but would
prefer to be able to do that in a single batch (clicking through to 250
or so to set it will be tedious).  It would be good to automate removing
all external URLs previously sniffed from the long-description, too.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGY5dkACgkQ+gerLs4ltQ5q7ACeOz96JWSdd7+cC8LNTlU7YzpF
mIEAmwVURbJGsoYQPGBns+1XK4lY3bwN
=/Uyr
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] easy_install failed to install numpy

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/19/2013 04:12 AM, Huiqun Zhou wrote:

 I'm trying to install numpy, but got the following error message.
 What's wrong?

NumPy and SciPy aren't setuptools-compatible.  You will need to follow
the directions on the SciPy site:

  http://www.scipy.org/Installing_SciPy


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGZMdcACgkQ+gerLs4ltQ6/sgCgu9oul6B8Rj9TzFxTH7VBVDxI
plEAnAr6VcU6VmAofTSYHomPwXoNGh6y
=NLjX
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 504 timeouts on pypi.python.org

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/18/2013 03:16 PM, Donald Stufft wrote:
 
 On May 17, 2013, at 6:29 PM, Tres Seaver tsea...@palladion.com
 wrote:
 
 Both in the web interface and in registration / upload of releases.
 

 Is this still happening to you?

This afternoon I was able to register / upload the release for which I
noticed the problem yesterday.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGX7l4ACgkQ+gerLs4ltQ6hLgCgw0eK/PNjmAWz12+LZqnLQfJt
TgYAoIzreHKL8WxXAzNMEyyNBuknC7h/
=djJM
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] 504 timeouts on pypi.python.org

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Both in the web interface and in registration / upload of releases.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGWr2IACgkQ+gerLs4ltQ5bAwCffg+Zn0MwHPaxrALbCSbHXeRP
1LEAoKMyu/z9nb1+nBSktEE0spAWYQ3W
=QIvr
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] distil 0.1.1 released

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/03/2013 02:24 PM, Noah Kantrowitz wrote:

 People expect package install as root to work like every other
 package system (yum, apt, take your pick) where they run sudo pip
 install a b c d and then run their app as a service-specific user.

I don't know any of those people:  either folks have learned *not* to
install as root, or else they run as root too.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGEAP4ACgkQ+gerLs4ltQ6odACfXcO7KHBYvPJhWOZCXMtMTZsn
bxIAn3j9jwRe70de+O0mIY4K2kfDrfzs
=WgtN
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP: Improving Python ZIP Application Support

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/30/2013 03:22 PM, Daniel Holth wrote:
 Python ZIP Application Support - 
 https://docs.google.com/document/d/1MKXgPzhWD5wIUpoSQX7dxmqgTZVO6l9iZZis8dnri78/edit?usp=sharing

+1,
 
but I think this actually belongs on python-dev (AFAICT it is
unrelated to distutils, setuptools, etc.)



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFXbbQACgkQ+gerLs4ltQ5+OgCgqP75xYWG8TGxiT3efvjZWe5U
YT4AoKTQJMhkbkU4KBoqmhOCDUl+5/Xo
=ERp8
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Catalog-sig] Merge catalog-sig and distutils-sig

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/28/2013 04:32 PM, PJ Eby wrote:
 On Thu, Mar 28, 2013 at 3:43 PM, Donald Stufft don...@stufft.io
 wrote:
 On Mar 28, 2013, at 3:39 PM, PJ Eby p...@telecommunity.com wrote:
 Can we do it by just dropping catalog-sig and keeping
 distutils-sig? I'm afraid we might lose some important
 distutils-sig population if the process involves renaming the
 list, resubscribing, etc.  I also *really* don't want to
 invalidate archive links to the distutils-sig archive.
 
 All in all, +1 on not having two lists, but I'm really worried
 about breaking distutils-sig.  We're still going to be talking
 about distribution utilities, after all.
 
 Worst case I'm sure subscribers can be transferred and the existing
 archive kept intact.
 
 That's a great way to have a bunch of people complaining that they 
 never subscribed to packaging-sig, not to mention the part where it 
 breaks everyone's mail filters.
 
 I really don't see any gains for renaming the list.  It's not like we 
 can go and scrub the entire internet of references to distutils-sig.

Not to mention breaking the gmane.org gateway, and those of us who sip
the firehose there instead of trying to swallow it via e-mail.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFUuS4ACgkQ+gerLs4ltQ4zXACguC0D2F3EEE7GT4DGXRa08hy7
FdYAoM56YpHef9J0ScKOdY2OHv/48LOv
=3UtH
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Builders vs Installers

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/26/2013 09:12 PM, PJ Eby wrote:
 (Some tools do check for the *existence* of a PKG-INFO, like PyPI's 
 sdist upload validation, and the various egg formats require a file 
 *named* PKG-INFO, but AFAIK nothing commonly used out there actually 
 *reads* PKG-INFO or gives a darn about its contents, except for that 
 version usecase mentioned above.)

I do have a tool (named 'pkginfo', funnily enough) which does parse them:

  https://pypi.python.org/pypi/pkginfo

  http://pythonhosted.org/pkginfo/

I use it in another tool, 'compoze', which allows me to build cureated
indexes from versions installed locally (e.g., after testing in a
virtualenv):

  https://pypi.python.org/pypi/compoze/

  http://docs.repoze.org/compoze/


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFTKBcACgkQ+gerLs4ltQ4x/wCfZsp/p60ELrQvTCXfdPMhuK1E
qJQAoJXvTlTSo1iy/KxylnuizPodbr25
=IJ6t
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP439 and backward compat / easy_install / distlib

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/26/2013 05:28 AM, Ronald Oussoren wrote:
 
 On 25 Mar, 2013, at 19:16, PJ Eby p...@telecommunity.com wrote:
 
 
 Also, as far as detecting the need for setuptools, I think that can
 be done just by noticing whether the PKG-INFO included in an sdist
 is metadata 2.0 or not.  If it is, then setuptools should be
 explicitly declared as a build-time dependency, otherwise it's not
 needed.  If it's an older metadata version, then you probably need
 setuptools.
 
 Is it even necessary to automaticly install setuptools?
 Setuptools-using package are supposed to use  ez_setup.py, or
 distribute_setup.py for distribute, to ensure that the setuptools
 package is available during setup.

No, they are not.  That usage was for bootstrapping in an era when
setuptools was not widely presetn.  Most packages have *removed* those
files today.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFRvPAACgkQ+gerLs4ltQ6XhgCgknMlM9drnL5KJKSvoEcuoKqw
60gAn1QyyUersaUdKXbJrpnJuu3AXkzz
=i63/
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] self.introduce(distutils-sig)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/20/2013 06:13 AM, Paul Moore wrote:

 Another nice tool would be some sort of Windows build farm, where 
 projects could submit a sdist and it would build wheels for a list of 
 supported Python versions and architectures. That wouldn't work for 
 projects with complex dependencies, obviously, but could cover a 
 reasonable-sized chunk of PyPI (especially if dependencies could be 
 added to the farm on request).

The Zope Foundation pays hosting charges for a box which runs Windows
tests for ZF projects, and also builds and uploads Windows binaries (eggs
and MSIs) for them when they are released.

  http://winbot.zope.org/

As an example, look at any recent zope.interface release, e.g.:

 https://pypi.python.org/pypi/zope.interface/4.0.5#downloads



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFKAP0ACgkQ+gerLs4ltQ6UZwCgkxfOtrArGn/F5dKPk6+QepWV
7jYAniBreYijRKhevNS6rDUteePNzfZW
=m0LP
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools-Distribute merge announcement

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for the announcment, and especially thanks to all those who have
worked on setuptools and distribute.  Particular thanks to PJE for having
both devised the thing and worked out how to get the community to adopt it.

I'm looking forward to the packaging BoF now, instead of dreading it.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFCCosACgkQ+gerLs4ltQ7qNgCgx+PDk8GYdmVIq1fbGdvqFt6K
EaEAniahF//OJkZQ/LVnJx6m1DqS0r+D
=0P09
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Add optional password_command .pypirc value

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/08/2013 12:57 PM, Donald Stufft wrote:
 If you're uploading via SSH you'll open a SSH tunnel and then POST to
 PyPI over that tunnel.

That isn't a hard requirment.  The PyPI software could add a command-line
script used for uploads which depended on the identity indicated by the
SSH-authenticated session.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlE6z+MACgkQ+gerLs4ltQ6DggCfZ62QIeUlx5A7A5cnuwU5jTqJ
pN8AoN0T0P20qwo5r5p7aheyYi3cGL2L
=SdYC
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [venv] distribute-0.6.35 fails on python 3.3?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/26/2013 04:20 AM, Marius Gedminas wrote:
 On Tue, Feb 26, 2013 at 09:17:29AM +, Paul Moore wrote:
 On 26 February 2013 06:21, Chris Withers ch...@simplistix.co.uk
 wrote:
 File ./setuptools/dist.py, line 103 except ValueError, e: ^ 
 SyntaxError: invalid syntax
 
 Can other people reproduce this? When was that Python 3
 incompatible except clause introduced?
 
 I quite often see this, it's usually because something that pip is 
 doing (building the metadata/dependency stuff, the actual code
 build is fine) is failing to run 2to3.
 
 I can't offer anything in the way of a fix, I'm afraid...
 
 How hard would it be to rewrite distribute to use a common language 
 subset instead of relying on 2to3?

The sheer number of developer hours saved by not waiting for the 2to3 run
every time a Py3k virtualenv is created should dwarf whatever effort is
involve.  Any volunteers to take on for the team?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlEs/CAACgkQ+gerLs4ltQ6oEgCcDobQyI2TbW5Ev0NDtxAOqSlJ
GBwAn3F4NMJ9nzY1/xmkxcvJdW8hceYp
=Bbmr
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal for incorporating buildout-versions on buildout (Re: Better version pinning in buildout (buildout-versions))

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/12/2013 04:53 PM, Maurits van Rees wrote:
 Is the develop-eggs directory always cleaned up during a buildout run 
 so only the eggs in the 'develop' option are listed there?

Yes.  See:


https://github.com/buildout/buildout/blob/master/src/zc/buildout/buildout.py#L438


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDx5XgACgkQ+gerLs4ltQ7KRgCfSpy6MMfZtlqOa5JNhOTH5opj
lJ0An2qCMPazGZIG3YuVeFSfaE2fZpwG
=PEaD
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] distlib and data files = resources ?

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/20/2012 10:21 PM, PJ Eby wrote:
 On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren
 ronaldousso...@mac.comwrote:
 
 
 On 19 Nov, 2012, at 20:26, PJ Eby p...@telecommunity.com wrote:
 
 
 Data files should never be installed to package directories.  But
 I'm
 not aware of any good reason why resource files should ever be
 installed anywhere *else*.
 
 To be (too) snarky: because the FHS says so.
 
 Less snarky, Linux distributors try to keep simular files together
 (for
 example storing all gettext translations together in
 /usr/share/locale). To play nice in such an enviroment Python
 packages would have to install resource files outside of the python
 package and into the FHS specified directory structure.
 
 
 Consider the example of a web page template containing embedded
 Python code.  Is that a data file containing code, or a code file
 containing data?  Where does the FHS say it goes?
 
 What if it's not embedded Python, but an embedded DSL interpreted by
 the package it goes with?
 
 What if it's not a page template, but a precompiled SQL grammar?
 (Such as was distributed with the gadfly package, many a year ago.)
 
 These are the kind of files I mean by resources.  If somebody wants
 to support gettext or similar localization, then obviously they should
 declare the files data -- or better yet, as part of an explicit
 localization category.
 
 The whole point of resources is that it's a catch-all for static
 data that's more convenient to treat as a standalone source file than
 to inline as a huge triple-quoted constant in a .py file.  ;-)

Exactly:  any dsitribution-packaer who tries to move such files out of
the package due to some misunderstood FHS-driven theory about such files
is just breaking the software to no purpose.

- -1 to enabling such misuse, as distinct from data / config files
which fall into other categories (documentation, example configs, etc.).
 Such files are not resources in any sensible use of the term.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCsTmsACgkQ+gerLs4ltQ4uBgCgnRRaQA0AjzaNOqPomSHOC7+s
19cAoMUl4FwpW6TDMAqSjG1Cj3bYx6bv
=w8D1
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] python setup.py develop and extras

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/06/2012 06:47 AM, Chris Withers wrote:
 On 05/11/2012 20:32, Daniel Holth wrote:
 Extras are just an alias for a set of dependencies. After you run 
 setup.py develop on package, just pip install
 package[docs,testing]
 
 it's pyramid, and I want to do setup.py develop [docs,testing]

FWIW, we lost this argument a while back and worked around it in Pyramid,
zope.*, and repoze.*.  the 'dev' and 'docs' aliases[1] do what you want:

  $ python setup.py dev docs


[]1 defined in 'setup.cfg'



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCZKSwACgkQ+gerLs4ltQ6R+wCg2qqDm8K2S55XKxAIr6wuP9Ux
XFMAoLhldG170K9DS39siHCQLtpbTrck
=aJs8
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [issue142] easy_install ignores 'headers' passed to setup()

[Tres Seaver]

New submission from Tres Seaver tsea...@palladion.com:

A bare distutils install of a package with 'headers' passed to 'setup()'
dispatches to 'install_headers', which copies the exported header files
into the system include path.

'easy_install' bypasses the distutils 'install()' when doing a normal
egg install, and does not re-implement the 'install_headers' dance.

Furthermore, the 'bdist_egg' it creates, even though it contains the
header files, has no metadata which would allow the installer to
discover that they should be copied.

--
messages: 669
nosy: tseaver
priority: bug
status: unread
title: easy_install ignores 'headers' passed to setup()

___
Setuptools tracker setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue142
___
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [issue142] easy_install ignores 'headers' passed to setup()

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/09/2012 11:13 AM, Tres Seaver wrote:
 
 New submission from Tres Seaver tsea...@palladion.com:
 
 A bare distutils install of a package with 'headers' passed to
 'setup()' dispatches to 'install_headers', which copies the exported
 header files into the system include path.
 
 'easy_install' bypasses the distutils 'install()' when doing a normal 
 egg install, and does not re-implement the 'install_headers' dance.
 
 Furthermore, the 'bdist_egg' it creates, even though it contains the 
 header files, has no metadata which would allow the installer to 
 discover that they should be copied.

Note that distribute has the same bug, which I reported here:

 https://bitbucket.org/tarek/distribute/issue/295


- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/7AqQACgkQ+gerLs4ltQ4/kwCfWEBYSY+dlEfD0b/QNxXnPNxA
lPcAoIj0XsQCu2AbPuVWYLEGmWpfKL4Y
=VNY3
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Adding Provides-Extra as an edit to PEP 345

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/06/2012 10:32 AM, Daniel Holth wrote:
 Add Provides-Extra: to PEP 345 and clarify Requires-Dist: name (1)
 is the same as Requires-Dist: name (==1)
 
 +1
 
 Great. How do we get https://bitbucket.org/dholth/python-peps merged 
 into hg.python.org/peps/ ?

Given that PEP 345 is already in 'Accepted' state, I'm not sure we can
just merge it in.  We might need to create a new PEP which extends PEP
345 and adds the feature (it likely needs to bump the 'Metadata-Version',
too).


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/2+PQACgkQ+gerLs4ltQ57KwCfWR5W+gL0bgLOLOcyyOlXCI7e
KTIAoLDLUTjNQjw9VA9Hx8R4rYbW5XqZ
=pl62
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] using ZSQLMethods pypi package in zope 2.13

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/11/2011 03:45 PM, Fernando Martins wrote:
 Hi,
 
 I am using zope 2.9.9 and I was trying a migration to 2.13.8 which I
  have installed with buildout. I am however struggling with this new
  system, much more complex than the simple old Products system.
 
 The zope instance contains a Products folder where I have been able
 to drop in a few packages (a subfolder in it, actually) from Pypi.
 
 However, ZSQLMethods contains the Shared subfolder which is a
 dependency for the ZSQLMethods and I don't know where to put Shared
 to make it work (it doesn't work under Products).
 
 Based on the buildout.cfg of ZSQLMethods, I did:
 
 [buildout] ... parts = ... zsql
 
 [zsql] recipe = zc.recipe.testrunner eggs = Products.ZSQLMethods
 
 However, running bin/buildout I got
 
 Error: Picked: Products.ZSQLMethods = 2.13.4

That error comes from having 'allow-picked-versions = false' in
buildout.cfg -- you then need to supply an explicit version for every
package.

 I guess it should not be so difficult to install ZSQLMethods, but I 
 can't really figure it out. Suggestions?

I think you want 'Products.ZSQLMethods' added to the 'eggs' value for
your 'instance' section, so that it is on the sys.path when running the
'instance' script.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4bZVgACgkQ+gerLs4ltQ7egACgsEvUswttXfNiW2HBKH3ethqV
kbUAnRhB6F4zstK7FYnuNGIvMR0YO7UE
=gKwx
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] [Errno 104] Connection reset by peer

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/30/2011 03:13 PM, Anton Panasenko wrote:
 Hi guys, 
 
 Who knows how to fix the problem: 
 
 Download error: [Errno 104] Connection reset by peer -- Some packages may not 
 be found! 

This error indicates either that you have a transient network failure,
or that your index server (likely pypi.python.org) is down.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3mOtIACgkQ+gerLs4ltQ6BpQCfQBUP1wtRYo8nNf0KHyoOHEVN
dN8AnAyaefXWkvyjjtffZR+CrqhC+y81
=jJ77
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Setuptools + specifying project's version

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/09/2011 03:29 PM, Ruslan Spivak wrote:
 Hi,
 
 In 
 http://peak.telecommunity.com/DevCenter/setuptools#specifying-your-project-s-version
 there is a statement that 2.1-rc2 means you've already released 2.1
 and an example
 
 
 
 parse_version('2.1-rc2')  parse_version('2.1')
 False
 
 
 
 Running the example gives quite the opposite result (setuptools-0.6c11):
 
 parse_version('2.1-rc2')  parse_version('2.1')
 True
 
 and actually it turns out that a pre-release tag 2.1rc2 is equal to
 the post-release tag 2.1-rc2
 
   parse_version('2.1-rc2') == parse_version('2.1rc2')
 True
 
 Does anyone have any idea why that's the case or is it a bug?

Likely a bug, due to the fact that nobody who could fix it uses
post-release tags (I can't see the point, myself) -- just make another
release already).



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3ITWkACgkQ+gerLs4ltQ4YogCfdXZw8noDKlQ/eRoBjz8Y1gO5
yN0Anj0seQNVfFw2iDGpmxpkrOpHIeRH
=IIDM
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] dependencies, pip and non-PyPI-hosted packages

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/26/2011 12:02 PM, Ernesto Posse wrote:
 On Sat, Apr 23, 2011 at 3:12 PM, Carl Meyer c...@oddbird.net wrote:


 On 04/23/2011 02:00 PM, P.J. Eby wrote:
 At 04:54 PM 4/22/2011 -0500, Carl Meyer wrote:
 No, it is calling the distribute setup. If you look at how your package
 is installed, you'll find it in an egg - that's a sure sign of
 setuptools/distribute. It's just that python setup.py install does not
 handle dependencies, even with setuptools/distribute.

 Uh, yes it does, actually.  (At least with setuptools, it does; don't
 know about distribute.)

 Erp. Yeah, you're right; just verified that it works fine with both
 setuptools and distribute. Dunno where I got that idea.

 Carl
 
 
 I'm confused now. I have tried both with setuptools alone (using
 ez_setup.py instead of distribute_setup.py) and distribute, and it
 doesn't work with distribute alone for me: it doesn't install the
 dependencies and gives me those warnings about 'install_requires' not
 being recognized.
 
 Any ideas about what could be wrong?

How are you invoking setup?  Should be something like:

  from setuptools import setup

  setup(name='your.package',
...
install_requires=['other.packaage'],
   )


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk23VXsACgkQ+gerLs4ltQ5O6gCfd8WzYUb6+bWlGvPC/ZUsfcHu
NtIAn1pFAvWtvTV8Slap6Iopl2sT/5UD
=Hi4F
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [issue124] Add support for installing test requirements to 'develop' command

[Tres Seaver]

New submission from Tres Seaver tsea...@palladion.com:

The attached patch adds a '--with-test-requirements' / '-t' option to the 
'develop' command:  the rationale is that when developing a package, one should
be able to run the tests without polluting the local checkout directory with
the eggs specified by its 'tests_require':  those eggs should be installed just
as the other ones mandated by 'install_requires'.

I would actually prefer to make this behavior the default, perhaps with a
command-line-switch to disable it, but think that backward compatibility
trumps that itch.

--
assignedto: pje
files: setuptools-0.6-develop-with_test_requirements.patch
messages: 606
nosy: pje, tseaver
priority: feature
status: unread
title: Add support for installing test requirements to 'develop' command
Added file: 
http://bugs.python.org/setuptools/file76/setuptools-0.6-develop-with_test_requirements.patch

___
Setuptools tracker setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue124
___=== modified file 'EasyInstall.txt'
--- EasyInstall.txt	2011-03-23 21:09:16 +
+++ EasyInstall.txt	2011-03-28 14:42:42 +
@@ -1218,6 +1218,8 @@
 
 
 0.6final
+ * Added ``--with-test-requirements`` flag to the 'develop' command.
+
  * Fixed AttributeError under Python 2.3 when processing HTTP authentication
URLs (i.e., ones with a ``user:password@host``).
 

=== modified file 'setuptools/command/develop.py'
--- setuptools/command/develop.py	2008-01-19 02:55:03 +
+++ setuptools/command/develop.py	2011-03-28 14:40:10 +
@@ -13,6 +13,7 @@
 user_options = easy_install.user_options + [
 (uninstall, u, Uninstall this source package),
 (egg-path=, None, Set the path to be used in the .egg-link file),
+(with-test-requirements, t, Install test requirements),
 ]
 
 boolean_options = easy_install.boolean_options + ['uninstall']
@@ -30,6 +31,7 @@
 def initialize_options(self):
 self.uninstall = None
 self.egg_path = None
+self.with_test_requirements = False
 easy_install.initialize_options(self)
 self.setup_path = None
 self.always_copy_from = '.'   # always copy eggs installed in curdir
@@ -100,6 +102,10 @@
 # postprocess the installed distro, fixing up .pth, installing scripts,
 # and handling requirements
 self.process_distribution(None, self.dist, not self.no_deps)
+# Install test requirements when developing.
+if self.with_test_requirements and self.distribution.tests_require:
+for tests_req in self.distribution.tests_require:
+self.easy_install(tests_req)
 
 
 def uninstall_link(self):

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] easy_install doesn't work when there are multiple Content-Length headers

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/28/2011 11:08 AM, Hoang Xuan Phu wrote:
 Hi all,
 
 Just today I'm using easy_install to install mechanize and it is failing
 with the error ValueError: invalid literal for int() with base 10: '382727,
 382727'. By reading the source code and looking at the headers I see that
 the server is returning 2 Content-Length headers (same value, 382727), which
 is turned into '382727, 382727'. Fixing this should be very easy and I can
 do it then submit a patch. I'm just wondering, as distutils seem to be in a
 forking process, what's the best way to solve this?

I reported this SF bug:

 http://sourceforge.net/apps/trac/sourceforge/ticket/18486

PJE has checked in my patch working around this bug.  See issue 123:

 http://bugs.python.org/setuptools/issue123


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2QvEMACgkQ+gerLs4ltQ6M8ACdEjNaxg1w3M2jCc0JuqfAJeLa
SG8AoLOfZdbIpvDwrgvidOk4g72i61zU
=ZoDQ
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [issue123] [PATCH] Tolerate responses with multiple Content-Length headers

[Tres Seaver]

New submission from Tres Seaver tsea...@palladion.com:

Some servers (e.g., wwwsearch.sourceforge.net) apparently send multiple
'Content-Length' headers, which causes setuptools to barf trying to convert
a 'length, length' string to an integer.

This bug breaks installing 'mechanize', which lists wwwsearch.sourceforge.net
as its Download-URL, and therefore causes a bunch of Zope-related tests to fail
(e.g., https://mail.zope.org/pipermail/cmf-tests/2011-March/014576.html ).

The attached patch uses 'headers.getheaders('Content-Length')[0] to use only
the first value found.

--
assignedto: pje
files: setuptools-multi_content_length.patch
messages: 598
nosy: pje, tseaver
priority: urgent
status: unread
title: [PATCH] Tolerate responses with multiple Content-Length headers
Added file: 
http://bugs.python.org/setuptools/file75/setuptools-multi_content_length.patch

___
Setuptools tracker setupto...@bugs.python.org
http://bugs.python.org/setuptools/issue123
___=== modified file 'setuptools/package_index.py'
--- setuptools/package_index.py	2010-02-01 16:42:04 +
+++ setuptools/package_index.py	2011-03-23 14:06:46 +
@@ -550,7 +550,9 @@
 bs = self.dl_blocksize
 size = -1
 if content-length in headers:
-size = int(headers[Content-Length])
+# Some servers return multiple Content-Length headrers :(
+content_length = headers.getheaders(Content-Length)[0]
+size = int(content_length)
 self.reporthook(url, filename, blocknum, bs, size)
 tfp = open(filename,'wb')
 while True:

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonv, take two

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/18/2011 03:20 PM, P.J. Eby wrote:
 At 02:44 PM 3/18/2011 -0400, Carl Meyer wrote:
 Apparently (I am Windows-ignorant) recent Windows versions do
 support symlinks?
 
 Technically, some Windows filesystems can support this.  In practice, 
 no user-visible tools actually support making or using them sanely, AFAIK.
 
 So, I suggest promoting symlinks as the standard way, with 
 binary-copying being a Windows-only workaround. 

Could the config file contain an optional hint for finding the right
stdlib in cases where the binary copy had been made?  I realize that
parsing a config file *without* the stdlib is painful:  perhaps looking
for a line starting with 'stdlib =' would be enough?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2DzZUACgkQ+gerLs4ltQ6YtgCfcXlvVYLfwaLLfbAkF9YzOzog
9ekAnAhVygL2APAWR+Cd5h5ePEYblbBN
=wazt
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonv, take two

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/18/2011 08:01 PM, Vinay Sajip wrote:
 Hi Carl,
 
 So, possibilities I see for addressing this:

 1. Decide that in real cases of real Python installations, it's so
 unlikely to happen that we won't worry about it. I think it's possible
 that this is acceptable; the biggest practical problem is likely to be
 people trying to test this out during PEP review from a not-installed
 checkout, just like you did. We'd have to be careful to instruct people
 that it doesn't work that way, and might also want to add a check in the
 env-creation script to verify that the created env works properly, and
 if it doesn't give them some clue why not.
 
 Yes, I think this is important to do, or at least to have -v output show which
 stdlib is being used.
 
 2. Decide that we just don't support copied binaries, only symlinked
 ones. Apparently (I am Windows-ignorant) recent Windows versions do
 support symlinks? So this might only involve dropping support for old
 Windows'? How important is it for a new feature like this to fully
 support all operating systems that Python supports? We could also not
 expose the copy-binary option to the user, but fall back to it if we
 have no symlinks; which ends up being option (1) but trying to narrow
 even more the potential breakage cases.
 
 Well, Windows XP is still pretty common and likely to remain so for some time.
 On Windows XP, symlinks don't work, but confusingly os.symlink exists on 
 recent
 Pythons (certainly 3.2). I had to make a patch in my virtualenv fork to handle
 this in copyfile: on XP, os.symlink raises NotImplementedError because the
 underlying Windows API function is missing.
 
 So, even if it's just for Windows, I think copying will need to be supported,
 but perhaps only from Pythons whose sys.prefix is correctly set.
 
 3. The fully-reliable fix would be to somehow give the copied binary a
 hint where to find the right standard library, and this would involve
 adding something to the algorithm in getpath.c. The hint could take the
 form of a key in the config file, but I'd really like to avoid fully
 parsing the config-file in C and then again in Python later on. The hint
 could also be some kind of specially-formatted comment line at the top
 of the config file, which would require less C code to find and parse?

 Any thoughts on this (or alternative solutions I haven't thought of) are
 most welcome.
 
 I know that ConfigParser format files are the first thing one thinks of, but
 perhaps a simpler C-parseable format deserves further consideration.

One possibility is to make the config file format just a sequence of
long-form command-line options, one per line, with the leading '--'
stripped.  This option would involve inventing a '--use-prefix' option
(bikeshedders, start your sprayguns ;), but would make parsing it a
mostly trivial exercise.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2D9bgACgkQ+gerLs4ltQ7VwwCfQku+E1AnGzAYTG6blRgiq6IF
n8MAoMGYbjS/E8+2l2LsvhYO2BhLGtEb
=mA1G
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pythonv, take two

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/17/2011 02:50 PM, Carl Meyer wrote:
 On 03/16/2011 11:04 PM, Barry Warsaw wrote:
 +1.  Time for a PEP?
 
 Working on a draft PEP. I'll push it to bitbucket to make collaboration
 easier - then the next step would be to present the draft on
 python-ideas, if I'm reading PEP 2 correctly?

Correct.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2CXVgACgkQ+gerLs4ltQ7UhwCdHAa2pk5ia3Ls9w4O6SADdeJ7
ehgAnibKo+/zwJ7aydUAYYbuk/xkmvxk
=K0bJ
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] easy_install installing beta version of psycopg2

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/16/2011 05:35 AM, Daniele Varrazzo wrote:
 Hello,
 
 trying to install psycopg2 via easy_install (distribute 0.6.14), the
 user received the version 2.4 beta2 instead of the latest stable
 2.3.1.
 
 2.4 beta2 has never been uploaded on PyPI and is not even listed in
 the http://pypi.python.org/simple/psycopg2/
 
 I think this is a serious issue. Any solution? Thanks.

easy_install is finding the link to 2.4 beta2 on the homepage
(http://initd.org/psycopg/) listed for the 2.3.2 release.  This is
documented behavior, FWIW:

 http://peak.telecommunity.com/DevCenter/EasyInstall#id6

You could work around that issue using '--allow-hosts' to restrict
downloads to those actually on PyPI:

 http://peak.telecommunity.com/DevCenter/EasyInstall#id13


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1b/TMACgkQ+gerLs4ltQ6LWACfVlH84UIFfQl4durQZdpvEVBl
JPcAn0m2GjSIzg4gbi47jxJix+dihuxn
=mvL8
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Testing modules from PyPI

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/12/2011 08:19 AM, cool-RR wrote:

 What would be a good workflow to do post-release testing of my PyPI
 packages? That is, I make a new release on PyPI, and I want to install it on
 a VM and run the tests on the installed version. What would be a good way to
 do it?

I use virtualenv, something like this::

 $ export WHERE=/tmp/test-yourpackage
 $ /path/to/python/bin/virtualenv --no-site-packages $WHERE
 $ $WHERE/bin/easy_install nose coverage
 $ $WHERE/easy_install --always-unzip yourpackage
 $ export TARGET=$WHERE/lib/python2.x/site-packages
 $ $WHERE/bin/nosetests  --where=$TARGET/yourpackage-x.y-python2.x.egg


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1Yn68ACgkQ+gerLs4ltQ6iVQCg0SxbRTQMUMRJA9frxpZqqa6i
IWsAn0NyCeQDQs4sGupc/M7OKL6OeIzr
=kA8g
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Buildout and non-pypi hosted packages

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/26/2011 10:25 AM, Tom Aratyn wrote:
 Hello,
 
 I work for an organization which would like to use buildout but we're
 hitting a problem with buildout and pyrtf (which is not hosted in the
 cheeseshop but is available off a url form sourceforge). Pip has no
 problem with this but I'm not sure how to get buildout to understand
 it.
 
 We're listing all our dependencies using install_requires. Is there a
 way to do this?

Check out the options here:

 http://pypi.python.org/pypi/zc.buildout#finding-distributions


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1AQVEACgkQ+gerLs4ltQ5aJgCgnez9eK6UNNsAH2UlxlH9O6TN
AbcAoKeiIOltlV9vLstKaLQ1fXbhEHfl
=TTff
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setuptools vs distribute on Debian

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/18/2010 10:51 AM, Manlio Perillo wrote:
 No, this is not a flame.
 
 I'm on Debian Squeeze and I noticed this strange thing:
 
 $sudo easy_install -U setuptools
 install_dir /usr/local/lib/python2.6/dist-packages/
 Searching for distribute
 Reading http://pypi.python.org/simple/distribute/
 Reading http://packages.python.org/distribute
 Best match: distribute 0.6.14
 Processing distribute-0.6.14-py2.6.egg
 distribute 0.6.14 is already the active version in easy-install.pth
 Installing easy_install script to /usr/local/bin
 Installing easy_install-2.6 script to /usr/local/bin
 
 Using /usr/local/lib/python2.6/dist-packages/distribute-0.6.14-py2.6.egg
 Processing dependencies for distribute
 Finished processing dependencies for distribute
 
 
 Now, I read that this is a Debian policy: for some reasons they force me
 to use distribute instead setuptools.
 
 However, I *do* want to use setuptools, and I'm unable to do what I want.
 I checked the fake setuptools source code but I can't see what I need
 to modify in order to get setuptools when I ask for setuptools.

If you use the OS tools to install from the OS repositories, you are
pretty much forced to live with any of their non-optional policy
choices.  Alternatives would be to go outside the box in one way or
another:

- - Install an existing .deb file which somebody else who agrees with you
  has built.

- - Build and install such a .deb file yourself, e.g. via 'apt-get source
  setuptools' and then hack on the build files.

- - Install setuptools into the system Python manually (probably a Really
  Bad Idea).

- - Install and use 'virtualenv' to get an environment insulated from
  the system Python.  'virtualenv' still uses the real setuptools by
  default.

- - Install Python and setuptools from source.


I prefer the last option, myself, as I know better than the OS packagers
do about how to configure and build Python and related stuff for my
applications, just as they know better how to build it to support other
system packages.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzlT40ACgkQ+gerLs4ltQ7ZYwCfROhAZcofntZNfFvTV5CqRo9v
J1oAn3AGDhRJyrSBzCSjTT1qS40MUibJ
=IEjs
-END PGP SIGNATURE-

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig