I've updated distlib[1] with a scripts API - functionality for installing
scripts.
The design and implementation covers shebang adjustment and optional native
Windows executable installation (like setuptools).
The update includes:
A short tutorial showing how to use the API. [2]
A discussion of
Not bad. The wheel installer could probably use the scripts wrapper.
On Thu, Sep 27, 2012 at 6:43 AM, Vinay Sajip wrote:
> I've updated distlib[1] with a scripts API - functionality for installing
> scripts.
>
> The design and implementation covers shebang adjustment and optional native
> Windows
What you can do with pkgutil is call
pkgutil.iter_importer_modules.register(importer, function) so that
your new importer works with iter_modules. Unfortunately even though
it implements most of what you would need to listdir() a zip file,
using zipimport._zip_directory_cache[], it does not expose
Daniel Holth gmail.com> writes:
>
> Not bad. The wheel installer could probably use the scripts wrapper.
>
Good to know, thanks. I noticed that the PEP referred to script installation but
didn't notice it in the wheel implementation.
Regards,
Vinay Sajip
On Wed, Sep 26, 2012 at 3:09 PM, Donald Stufft wrote:
> I've been comparing how PEP386/distutils2.version treats versions
> and how pkg_resources from setuptools treats versions and it
> confirmed a worry of me with the way that dev is treated in PEP386.
>
> In PEP386 you have several kinds of "to
On Wed, Sep 26, 2012 at 4:24 PM, Donald Stufft wrote:
> On Wednesday, September 26, 2012 at 4:00 PM, Toshio Kuratomi wrote:
>
> Note that this was an intentional difference with setuptools.
>
> Do you have any idea _why_? It seems from my perspective (of someone
> who wasn't really paying attentio
Daniel Holth gmail.com> writes:
>
> What you can do with pkgutil is call
> pkgutil.iter_importer_modules.register(importer, function) so that
> your new importer works with iter_modules. Unfortunately even though
> it implements most of what you would need to listdir() a zip file,
> using zipimp
On Thu, Sep 27, 2012 at 9:12 AM, Erik Bray wrote:
> On Wed, Sep 26, 2012 at 4:24 PM, Donald Stufft
> wrote:
>> On Wednesday, September 26, 2012 at 4:00 PM, Toshio Kuratomi wrote:
>>
>> Note that this was an intentional difference with setuptools.
>>
>> Do you have any idea _why_? It seems from m
On Thu, Sep 27, 2012 at 9:14 AM, Vinay Sajip wrote:
> I haven't defined any new importers. In terms of listing a whole zip's
> contents,
> that's not part of the idea of a resource: you need to know what resource you
> want, before you can get it, at least at the top level. Of
> course, you can i
On Thursday, September 27, 2012 at 9:12 AM, Erik Bray wrote:
> My guess--and this is pure speculation as I wasn't following the
> original discussions either--is that it fell out of the desire to
> require versions to be lexicographically ordered. So "dev" would
> *have* to come after "a", "b", and
On Thu, Sep 20, 2012 at 10:19 PM, Stanley A. Klein wrote:
> So, please add the FHS issue to your list.
>
> I've also found that everything seems to be in a state of flux right now,
> with setuptools, distribute, distutils, distutils2, and
> pypi2rpm/bdist_rpm2 all out there and bumping into each o
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé ziade.org> writes:
On a side note, since these are the original modules that were taking
out of Python's packaging implementation,
I don't think you can copyright them under your name like what I have
seen in setup.py
AFAIK I've only added m
On 27 September 2012 15:01, Tarek Ziadé wrote:
> I think it's perfectly fine to have hg.python.org/distlib and do what you
> described.
>
> It can mature there - it does not bother cpython or other repositories.
One advantage of distlib being on bitbucket is that anyone can fork it
and create pul
On 9/27/12 4:22 PM, Paul Moore wrote:
On 27 September 2012 15:01, Tarek Ziadé wrote:
I think it's perfectly fine to have hg.python.org/distlib and do what you
described.
It can mature there - it does not bother cpython or other repositories.
One advantage of distlib being on bitbucket is that
(Sorry, meant to post to the list)
On 27 September 2012 15:26, Tarek Ziadé wrote:
> But then, unless I am mistaken, you have to ask each contributor to sign the
> agreement to avoid any issue the day it goes into Python.
TBH, I'm not sure. I've contributed some patches to Python via the
tracker,
On 9/27/12 4:40 PM, Paul Moore wrote:
(Sorry, meant to post to the list)
On 27 September 2012 15:26, Tarek Ziadé wrote:
But then, unless I am mistaken, you have to ask each contributor to sign the
agreement to avoid any issue the day it goes into Python.
TBH, I'm not sure. I've contributed so
Le jeudi 27 septembre 2012 à 16:01 +0200, Tarek Ziadé a écrit :
> On 9/26/12 11:58 PM, Vinay Sajip wrote:
> > Tarek Ziadé ziade.org> writes:
> >
> >> On a side note, since these are the original modules that were taking
> >> out of Python's packaging implementation,
> >> I don't think you can copy
On 9/27/12 4:28 PM, Antoine Pitrou wrote:
Le jeudi 27 septembre 2012 à 16:01 +0200, Tarek Ziadé a écrit :
On 9/26/12 11:58 PM, Vinay Sajip wrote:
Tarek Ziadé ziade.org> writes:
On a side note, since these are the original modules that were taking
out of Python's packaging implementation,
I d
Tarek Ziadé ziade.org> writes:
> > There are two of us maintaining hg.python.org: Georg and I. So, I don't
> > know about Georg, but I don't want to maintain repositories for every
> > third-party library that might one day become part of Python. OTOH, if
> > Georg wants to handle it, then fine
>
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé ziade.org> writes:
There are two of us maintaining hg.python.org: Georg and I. So, I don't
know about Georg, but I don't want to maintain repositories for every
third-party library that might one day become part of Python. OTOH, if
Georg wan
On Thu, Sep 27, 2012 at 09:25:51AM -0400, Donald Stufft wrote:
> On Thursday, September 27, 2012 at 9:12 AM, Erik Bray wrote:
>
> My guess--and this is pure speculation as I wasn't following the
> original discussions either--is that it fell out of the desire to
> require versions to b
On 09/27/2012 05:49 PM, Tarek Ziadé wrote:
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé ziade.org> writes:
There are two of us maintaining hg.python.org: Georg and I. So, I don't
know about Georg, but I don't want to maintain repositories for every
third-party library that might one d
Tarek Ziadé ziade.org> writes:
> I would just leave it in hg.python.org and drop any single author
> header, and
> have the project driven by the community under the PSF governance.
>
> If we want to thank contributors like you or me or anyone that helped in
> this code
> base we can always ma
Georg Brandl gmx.net> writes:
>
> No, but I can see why you want it there, and I for one have no problems
> creating and maintaining that repository.
>
Great. Thanks!
>
> And we'd like to keep it that way.
>
:-)
>
> Are you sure you're not overreacting?
>
> All that Antoine is saying is t
On 9/27/12 6:37 PM, Georg Brandl wrote:
On 09/27/2012 05:49 PM, Tarek Ziadé wrote:
On 9/27/12 5:40 PM, Antoine Pitrou wrote:
Tarek Ziadé ziade.org> writes:
There are two of us maintaining hg.python.org: Georg and I. So, I
don't
know about Georg, but I don't want to maintain repositories for
On Thursday, September 27, 2012 at 11:59 AM, Toshio Kuratomi wrote:
> setuptools allows any random string into the versions. Certain strings have
> special meaning. Unknown strings are lexicographically sorted. Rereading
> this section of the PEP
> http://www.python.org/dev/peps/pep-0386/#caveats-o
Le 27/09/2012 11:59, Toshio Kuratomi a écrit :
> * a, b, c, and rc are the typical alpha beta release candidate tags. We
> debated whether to allow the single letter versions or the long versions
> "alpha", "beta", "rc". In the end, which set of tags was used was
> a bikeshed argument so it
On Thu, Sep 27, 2012 at 1:46 PM, Éric Araujo wrote:
> Le 27/09/2012 11:59, Toshio Kuratomi a écrit :
>> * a, b, c, and rc are the typical alpha beta release candidate tags. We
>> debated whether to allow the single letter versions or the long versions
>> "alpha", "beta", "rc". In the end, wh
On Thu, Sep 27, 2012 at 1:50 PM, Daniel Holth wrote:
> Ruby gems use http://semver.org/
I don't remember if I was involved in the past discussions (it's possible),
but I'm in favor of using (and requiring) semantic versioning, if only
because we don't have to invent notation or interpretation.
On Thu, Sep 27, 2012 at 01:00:10PM -0400, Donald Stufft wrote:
> On Thursday, September 27, 2012 at 11:59 AM, Toshio Kuratomi wrote:
>
> I would be for renaming .dev to .pre[1]_ but I would be against the rest
> of
> this
> proposal. Having one and only one way to spell things was one
On Thu, Sep 27, 2012 at 5:58 PM, Fred Drake wrote:
> On Thu, Sep 27, 2012 at 1:50 PM, Daniel Holth wrote:
>> Ruby gems use http://semver.org/
>
> I don't remember if I was involved in the past discussions (it's possible),
> but I'm in favor of using (and requiring) semantic versioning, if only
>
This is the worst bikeshed topic. I would like to keep PEP-386 as much
as possible, only because the time-consuming agreement has already
happened.
For wheel I had to add an alphanumeric build number apart from the
main version because you need to be able to distinguish e.g. a RHEL
build from a De
On Thu, Sep 27, 2012 at 01:46:25PM -0400, Éric Araujo wrote:
> Le 27/09/2012 11:59, Toshio Kuratomi a écrit :
> > * a, b, c, and rc are the typical alpha beta release candidate tags. We
> > debated whether to allow the single letter versions or the long versions
> > "alpha", "beta", "rc". In
On Thursday, September 27, 2012 at 2:03 PM, Toshio Kuratomi wrote:
> That's your preference, not capability. I'd also say you should use
> 1.0.post1 rather than 1.0a1pre1.
So how do you encode the very first development release then if you're
using post? Can you point me towards somewhere where
On Thu, Sep 27, 2012 at 02:42:50PM -0400, Donald Stufft wrote:
>
> On Thursday, September 27, 2012 at 2:03 PM, Toshio Kuratomi wrote:
>
> That's your preference, not capability. I'd also say you should use
> 1.0.post1 rather than 1.0a1pre1.
>
> So how do you encode the very first develop
On Thursday, September 27, 2012 at 3:45 PM, Toshio Kuratomi wrote:
> then that works perfectly fine for me. To put out a snapshot between rc and
> final, I'd do 0.2rc1.post1 so not having a pre/dev in there doesn't bother
> me.
>
> However, now that you mention it, ISTR that this is the way that i
On Wed, Sep 26, 2012 at 10:38 PM, Alex Clark wrote:
> On 2012-09-26 15:35:00 +, Jim Fulton said:
>
>> On Wed, Sep 26, 2012 at 11:03 AM, Conrado Buhrer
>> wrote:
>>>
>>> Hi Jim,
>>>
>>> A few of us on #buildout@freenode have noticed the issue, we believe
>>> that some links on pypi are the cau
On Thu, Sep 27, 2012 at 2:45 PM, Toshio Kuratomi wrote:
> However, now that you mention it, ISTR that this is the way that it was
> originally and the lack of pre/dev in that position did bother another (set
> of?) the PEP authors enough that it was changed. For me, switching the
> search order
Tarek Ziadé ziade.org> writes:
>
> I've also said that I believed that it's simpler to include back wrt
> licensing if it's a code base
> that's under the contributors agreement.
What does that have to do with hg.p.o? You can ask contributor agreements if
your code is hosted on bitbucket. There
On Thu, Sep 27, 2012 at 05:00:56PM -0500, Brad Allen wrote:
> On Thu, Sep 27, 2012 at 2:45 PM, Toshio Kuratomi wrote:
>
> > However, now that you mention it, ISTR that this is the way that it was
> > originally and the lack of pre/dev in that position did bother another (set
> > of?) the PEP auth
On Thursday, September 27, 2012 at 7:15 PM, Toshio Kuratomi wrote:
> Some organizations and projects use it one way and others the other way.
> And unlike alpha, beta, rc ordering which is both long established in the
> computing industry and based on the sorting of the greek alphabet, the
> choice
On 9/28/12 12:55 AM, Antoine Pitrou wrote:
Last but not least, distlib is the plan forward endorsed by python-dev,
Is it? I haven't seen a PEP or an official decision about that. Just because
someone proposed it on a mailing-list doesn't mean it is "endorsed by
python-dev".
We discussed about
Tarek Ziadé ziade.org> writes:
>
> On 9/28/12 12:55 AM, Antoine Pitrou wrote:
> >> Last but not least, distlib is the plan forward endorsed by python-dev,
> > Is it? I haven't seen a PEP or an official decision about that. Just because
> > someone proposed it on a mailing-list doesn't mean it is
On Thu, 2012-09-27 at 16:15 -0700, Toshio Kuratomi wrote:
> On Thu, Sep 27, 2012 at 05:00:56PM -0500, Brad Allen wrote:
> > On Thu, Sep 27, 2012 at 2:45 PM, Toshio Kuratomi wrote:
> >
> > > However, now that you mention it, ISTR that this is the way that it was
> > > originally and the lack of pr
On Fri, Sep 28, 2012 at 9:37 AM, Tarek Ziadé wrote:
> On 9/28/12 12:55 AM, Antoine Pitrou wrote:
>>>
>>> Last but not least, distlib is the plan forward endorsed by python-dev,
>>
>> Is it? I haven't seen a PEP or an official decision about that. Just
>> because
>> someone proposed it on a mailing
On Thursday, September 27, 2012 at 8:03 PM, Chris McDonough wrote:
> The tools that people use to install a Python package sort it before
> alpha and have for many years. That seems to be a pretty good argument
> in favor, all other things considered.
>
Yes this is what I've been trying to say, I
The wheel strategy has just been to implement the peps in setuptools
and in pkg_resources. It is nearly effortless to do so since the PEPs
are so similar to the existing system of eggs. Plus you get to play
with it using 900 * 1.6 ** (year-2005) packages.
Afterwards, with binary packages, you can
On 09/27/2012 06:48 PM, Vinay Sajip wrote:
Georg Brandl gmx.net> writes:
No, but I can see why you want it there, and I for one have no problems
creating and maintaining that repository.
Great. Thanks!
And we'd like to keep it that way.
:-)
Are you sure you're not overreacting?
A
Hi,
On 2012-09-27 21:12:05 +, Jim Fulton said:
On Wed, Sep 26, 2012 at 10:38 PM, Alex Clark wrote:
On 2012-09-26 15:35:00 +, Jim Fulton said:
On Wed, Sep 26, 2012 at 11:03 AM, Conrado Buhrer
wrote:
Hi Jim,
A few of us on #buildout@freenode have noticed the issue, we believe
that
49 matches
Mail list logo
