On 17 July 2013 23:18, Brett Cannon wrote:
> As of right now the User's Guide doesn't mention using setuptools for
> building (beyond an empty header listing) and goes with the old distutils
> setup.py approach. It also words things like you don't know how to really
> use Python and are starting
On Jul 18, 2013, at 3:20 AM, Paul Moore wrote:
> On 17 July 2013 23:18, Brett Cannon wrote:
> As of right now the User's Guide doesn't mention using setuptools for
> building (beyond an empty header listing) and goes with the old distutils
> setup.py approach. It also words things like you do
Sorry, accidentally left distutils-sig off when replying.
- Forwarded Message -
> From: Vinay Sajip
> To: Nick Coghlan
> Cc:
> Sent: Thursday, 18 July 2013, 8:41
> Subject: Re: [Distutils] Q about best practices now (or near future)
>
>> From: Nick Coghlan
>
>
>
>> Then (help) w
On 18 July 2013 08:29, Donald Stufft wrote:
> Personally I think pip should be vendoring setuptools regardless. A
> package manager with dependencies is strange and there have been quite a
> few problems caused by setuptools getting in a bad state.
Agrred on the dependency point (but I don't co
> It's for more reasons than it's in the standard library. setuptools has
> had a lot of misfeatures and a good bit of the angst against not using
> setuptools was due to easy_install not setuptools itself.
It's hard to disentangle the two - it's not as if the easy_install
functionality is compl
On 18 July 2013 16:45, Paul Moore wrote:
> On 18 July 2013 02:03, Donald Stufft wrote:
>>
>> it's simple to upgrade the pip if the user requires a newer version
>> of pip using ``pip install --upgrade pip`
>
>
> Please don't gloss over the potential issues with upgrading in the face of
> in-use e
On 18 July 2013 08:57, Nick Coghlan wrote:
> Shipping an msi installer for pip (perhaps bundling with setuptools)
> would also be an acceptable alternative.
>
-1.
I would suggest that this approach, if it were considered seriously, should
be reviewed carefully by someone who understands MSI ins
On 18 July 2013 18:10, Paul Moore wrote:
> On 18 July 2013 08:57, Nick Coghlan wrote:
>>
>> Shipping an msi installer for pip (perhaps bundling with setuptools)
>> would also be an acceptable alternative.
>
>
> -1.
>
> I would suggest that this approach, if it were considered seriously, should
>
On 18 July 2013 17:50, Vinay Sajip wrote:
>> It's for more reasons than it's in the standard library. setuptools has
>
>> had a lot of misfeatures and a good bit of the angst against not using
>> setuptools was due to easy_install not setuptools itself.
>
> It's hard to disentangle the two - it's
On Jul 18, 2013, at 4:22 AM, Nick Coghlan wrote:
> On 18 July 2013 18:10, Paul Moore wrote:
>> On 18 July 2013 08:57, Nick Coghlan wrote:
>>>
>>> Shipping an msi installer for pip (perhaps bundling with setuptools)
>>> would also be an acceptable alternative.
>>
>>
>> -1.
>>
>> I would sug
On 18 July 2013 17:44, Vinay Sajip wrote:
> Sorry, accidentally left distutils-sig off when replying.
Since I already replied off list, there's no way this dual
conversation over the same emails will get confusing, nope, uh-uh :)
> - Forwarded Message -
>> From: Vinay Sajip
>> To: Nick
On Wed, Jul 17, 2013 at 21:46 -0400, Donald Stufft wrote:
> As I've mentioned before an online key (as is required by PyPI) means
> that if someone compromises PyPI they compromise the key. It seems to
> me that TUF is really designed to handle the case of the Linux
> distribution (or similar) wher
> It would actually be nice if "pkg_resources" and
> "setuptools-core"
> were available as separate PyPI distributions, and setuptools bundled
> them together with easy_install.
This would seem to require quite a sizeable refactoring of setuptools, since
the easy_install command is just an entr
On 17 July 2013 22:43, Nick Coghlan wrote:
>
> On 18 Jul 2013 01:46, "Daniel Holth" wrote:
>>
>> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon wrote:
>> > I'm going to be pushing an update to one of my projects to PyPI this
>> > week
>> > and so I figured I could use this opportunity to help wi
On 18 Jul 2013 21:48, "Oscar Benjamin" wrote:
>
> On 17 July 2013 22:43, Nick Coghlan wrote:
> >
> > On 18 Jul 2013 01:46, "Daniel Holth" wrote:
> >>
> >> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon
wrote:
> >> > I'm going to be pushing an update to one of my projects to PyPI this
> >> > wee
On 18 Jul, 2013, at 13:48, Oscar Benjamin wrote:
> On 17 July 2013 22:43, Nick Coghlan wrote:
>>
>> On 18 Jul 2013 01:46, "Daniel Holth" wrote:
>>>
>>> On Wed, Jul 17, 2013 at 11:12 AM, Brett Cannon wrote:
I'm going to be pushing an update to one of my projects to PyPI this
week
>
Abstract
This PEP proposes a way to represent the setuptools “entry points”
feature in standard Python metadata. Entry points are a useful
mechanism for advertising or discovering plugins or other exported
functionality without having to depend on the module namespace. Since
the feature is used by
On 18 July 2013 14:03, Daniel Holth wrote:
> Abstract
>
> This PEP proposes a way to represent the setuptools “entry points”
> feature in standard Python metadata. Entry points are a useful
> mechanism for advertising or discovering plugins or other exported
> functionality without having to depe
I would like to write a script to automatically register release URLs
for PyPI packages.
Is the REST API documented somewhere, or is the implementation the
spec ? ;-)
And related to this:
Will there be an option to tell PyPI's CDN to cache the release
URL's contents ?
Thanks,
--
Marc-Andre Lem
On Thu, Jul 18, 2013 at 9:27 AM, Paul Moore wrote:
> On 18 July 2013 14:03, Daniel Holth wrote:
>>
>> Abstract
>>
>> This PEP proposes a way to represent the setuptools “entry points”
>> feature in standard Python metadata. Entry points are a useful
>> mechanism for advertising or discovering plu
On 18 July 2013 13:13, Nick Coghlan wrote:
>
> On 18 Jul 2013 21:48, "Oscar Benjamin" wrote:
>
>> In another thread you mentioned the idea that someone would build
>> without using distutils/setuptools by using a setup.py that simply
>> invokes an alternate build system that is build-required by
On Jul 18, 2013, at 7:10 AM, M.-A. Lemburg wrote:
> I would like to write a script to automatically register release URLs
> for PyPI packages.
>
> Is the REST API documented somewhere, or is the implementation the
> spec ? ;-)
>
> And related to this:
>
> Will there be an option to tell PyPI's
>
> It would actually be nice if "pkg_resources" and "setuptools-core"
> were available as separate PyPI distributions, and setuptools bundled
> them together with easy_install. It's a *long* way down the priority
> list thing (and will likely never make it to the top, although it may
> be more pra
On Jul 18, 2013, at 8:06 AM, Noah Kantrowitz wrote:
>
> On Jul 18, 2013, at 7:10 AM, M.-A. Lemburg wrote:
>
>> I would like to write a script to automatically register release URLs
>> for PyPI packages.
>>
>> Is the REST API documented somewhere, or is the implementation the
>> spec ? ;-)
>>
Marcus Smith gmail.com> writes:
> the idea to have pip vendor setuptools crumbles a bit due to console
scripts
needing pkg_resources.
They don't *need* pkg_resources. All they're doing is taking a module name
and the name of a nested object in the form 'a.b.c', and distlib-generated
scripts
On Thu, Jul 18, 2013 at 12:12 PM, Marcus Smith wrote:
>
>>
>> It would actually be nice if "pkg_resources" and "setuptools-core"
>> were available as separate PyPI distributions, and setuptools bundled
>> them together with easy_install. It's a *long* way down the priority
>> list thing (and will
On Thu, Jul 18, 2013 at 9:49 AM, Vinay Sajip wrote:
> Marcus Smith gmail.com> writes:
>
> > the idea to have pip vendor setuptools crumbles a bit due to console
> scripts
> needing pkg_resources.
>
> They don't *need* pkg_resources. All they're doing is taking a module name
> and the name of a ne
I tried it out. pip can install setuptools when only pkg_resources is
installed. The only thing stopping it is a small check for whether the
current setuptools is of the distribute variety.
On Thu, Jul 18, 2013 at 12:53 PM, Daniel Holth wrote:
> On Thu, Jul 18, 2013 at 12:12 PM, Marcus Smith wro
> I think it's still useful to have pip vendor just pkg_resources (as
> pip.pkg_resources). It's easy, it gives you enough to install wheels,
> and it's not the only thing you would do.
I agree. there's 2 problems to be solved here
1) making pip a self-sufficient wheel installer (which require
Daniel Holth gmail.com> writes:
> On Thu, Jul 18, 2013 at 9:27 AM, Paul Moore gmail.com>
wrote:
> It is an extension so it can be a separate PEP, since there's enough
> to talk about in the main PEP. The document tries to write down what
> setuptools does in a straightforward json way.
If th
On Thu, Jul 18, 2013 at 1:01 PM, Marcus Smith wrote:
>
>
> On Thu, Jul 18, 2013 at 9:49 AM, Vinay Sajip
> wrote:
>>
>> Marcus Smith gmail.com> writes:
>>
>> > the idea to have pip vendor setuptools crumbles a bit due to console
>> scripts
>> needing pkg_resources.
>>
>> They don't *need* pkg_res
Marcus Smith gmail.com> writes:
> pkg_resources scripts confirm the version. don't see that here? not
necessary?
The load_entry_point needs the dist name because of how it's implemented - it
defers to the distribution instance. AFAICT there are no actual checks.
def load_entry_point(dist,
Marcus Smith gmail.com> writes:
>
>
>
> I think it's still useful to have pip vendor just pkg_resources (as
> pip.pkg_resources). It's easy, it gives you enough to install wheels,
> and it's not the only thing you would do.
>
> I agree. there's 2 problems to be solved here
>
> 1) making pi
On Thu, Jul 18, 2013 at 1:50 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> On Thu, Jul 18, 2013 at 9:27 AM, Paul Moore gmail.com>
> wrote:
>
>> It is an extension so it can be a separate PEP, since there's enough
>> to talk about in the main PEP. The document tries to write down
> The load_entry_point needs the dist name because of how it's implemented -
> it
> defers to the distribution instance. AFAICT there are no actual checks.
>
> def load_entry_point(dist, group, name):
> """Return `name` entry point of `group` for `dist` or raise
> ImportError"""
> return ge
>
> Perhaps you're forgetting that there already is an internal pkg_resources
> equivalent in my pip-distlib branch - this is a pkg_resources compatibility
> shim using pip.vendor.distlib which passed all the pip tests when it was
> submitted as a PR.
>
: ) no I haven't forgotten. I actually br
On Thu, Jul 18, 2013 at 10:58 AM, Liam Kirsher wrote:
> Marcus,
>
> Thanks! After reading that I think I can fix this by installing pip 1.4.
>
you can also make your recipe run "pip install -U setuptools" separately
before moving on to the supervisor upgrade. that will work and is maybe
easie
On Jul 18, 2013, at 12:42 PM, Noah Kantrowitz wrote:
>
> On Jul 18, 2013, at 8:06 AM, Noah Kantrowitz wrote:
>
>>
>> On Jul 18, 2013, at 7:10 AM, M.-A. Lemburg wrote:
>>
>>> I would like to write a script to automatically register release URLs
>>> for PyPI packages.
>>>
>>> Is the REST API
On Thu, Jul 18, 2013 at 2:19 PM, Marcus Smith wrote:
>
>>
>> Perhaps you're forgetting that there already is an internal pkg_resources
>> equivalent in my pip-distlib branch - this is a pkg_resources
>> compatibility
>> shim using pip.vendor.distlib which passed all the pip tests when it was
>> su
On Thu, Jul 18, 2013 at 1:24 PM, Marcus Smith wrote:
>
>> I think it's still useful to have pip vendor just pkg_resources (as
>> pip.pkg_resources). It's easy, it gives you enough to install wheels,
>> and it's not the only thing you would do.
>
>
> I agree. there's 2 problems to be solved here
>
On 18 July 2013 18:24, Marcus Smith wrote:
>
> I think it's still useful to have pip vendor just pkg_resources (as
>> pip.pkg_resources). It's easy, it gives you enough to install wheels,
>> and it's not the only thing you would do.
>
>
> I agree. there's 2 problems to be solved here
>
> 1) maki
On Jul 18, 2013, at 4:36 PM, Paul Moore wrote:
> On 18 July 2013 18:24, Marcus Smith wrote:
>
> I think it's still useful to have pip vendor just pkg_resources (as
> pip.pkg_resources). It's easy, it gives you enough to install wheels,
> and it's not the only thing you would do.
>
> I agree.
On 18 July 2013 21:41, Donald Stufft wrote:
> Console scripta aren't the only use of entry points fwiw. THere's other
> entry points programs use. I don't know if they all depend on setuptools or
> if just assume it's there. Technically the should depend but that would
> break things for those pe
> virtualenv /tmp/builder
> /tmp/builder/bin/pip wheel -w /tmp/wheels -r requirements.txt
>
people will expect to be able to do this globally (i.e not in a
virtualenv). that's when the headache starts
It does not try to avoid the non-problem of installing setuptools when you
> actually need it
>
fyi, I'm updating donald's original setuptools bundle issue with all of
this as the choices become clearer
https://github.com/pypa/pip/issues/1049
On Thu, Jul 18, 2013 at 2:08 PM, Marcus Smith wrote:
>
> virtualenv /tmp/builder
>> /tmp/builder/bin/pip wheel -w /tmp/wheels -r requirements.txt
>>
On Thu, Jul 18, 2013 at 1:50 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>> For one thing you can have more than one mysql = in the same
>> sqlalchemy.dialects. I think in this instance the string parsing is
>
> Don't you say in the PEP about the key that "It must be locally unique
>
On 18 July 2013 22:08, Marcus Smith wrote:
> it's a practical problem for users, due to being currently responsible for
> fulfilling the setuptools dependency themselves in non-virtualenv
> environments
> IMO, we need to bundle or install it for them (through dynamic installs,
> or add the logic
On Jul 18, 2013, at 5:56 PM, Paul Moore wrote:
> On 18 July 2013 22:08, Marcus Smith wrote:
> it's a practical problem for users, due to being currently responsible for
> fulfilling the setuptools dependency themselves in non-virtualenv environments
> IMO, we need to bundle or install it for t
On Thu, Jul 18, 2013 at 4:36 PM, Paul Moore wrote:
> As regards console scripts, I think they should be rewritten to remove the
> dependency on pkg_resources. That should be a setuptools fix,
As others have already mentioned, this is not a bug but a feature.
Setuptools-generated scripts are linke
I actually now plan to make scripts and exports first class citizens in PEP
426, with pydist-scripts.json and pydist-exports.json as extracted summary
files (like the existing pydist-dependencies.json).
They're important enough to include directly.
Cheers,
Nick.
__
On Thu, Jul 18, 2013 at 5:56 PM, Paul Moore wrote:
> On 18 July 2013 22:08, Marcus Smith wrote:
>>
>> it's a practical problem for users, due to being currently responsible for
>> fulfilling the setuptools dependency themselves in non-virtualenv
>> environments
>> IMO, we need to bundle or instal
On 19 Jul 2013 08:42, "Nick Coghlan" wrote:
>
> I actually now plan to make scripts and exports first class citizens in
PEP 426, with pydist-scripts.json and pydist-exports.json as extracted
summary files (like the existing pydist-dependencies.json).
>
> They're important enough to include directl
On Thu, Jul 18, 2013 at 6:42 PM, Nick Coghlan wrote:
> I actually now plan to make scripts and exports first class citizens in PEP
> 426, with pydist-scripts.json and pydist-exports.json as extracted summary
> files (like the existing pydist-dependencies.json).
>
> They're important enough to incl
OH -scripts would be the distutils-style scrips.
On Thu, Jul 18, 2013 at 6:51 PM, Daniel Holth wrote:
> On Thu, Jul 18, 2013 at 6:42 PM, Nick Coghlan wrote:
>> I actually now plan to make scripts and exports first class citizens in PEP
>> 426, with pydist-scripts.json and pydist-exports.json as
>
> I'll see if I can do a patch. I don't think it will be hard at all,
> and I do think it's work that will eventually become necessary.
>
patch for which solution?
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/l
PJ Eby telecommunity.com> writes:
> As others have already mentioned, this is not a bug but a feature.
> Setuptools-generated scripts are linked to a specific version of the
> project, which means that you can install more than one version by
> renaming the scripts or installing the scripts to di
Daniel Holth gmail.com> writes:
> PJE is correct that if we surprise people with non-pkg_resources
> console_scripts then we will break things for people who are more
> interested in a working packaging experience.
Do you mean that you think multiple versions have to be supported, and that's
wh
On Jul 18, 2013, at 7:20 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> PJE is correct that if we surprise people with non-pkg_resources
>> console_scripts then we will break things for people who are more
>> interested in a working packaging experience.
>
> Do you mean that yo
> I think the point is that people might be dependent on this functionality and
> changing it out from underneath them could break their world.
I got the point that Daniel made, and my question was about *how* their world
would break, and whether we really need to support multiple versions of
On Thu, Jul 18, 2013 at 7:09 PM, Vinay Sajip wrote:
> PJ Eby telecommunity.com> writes:
>> While other strategies are definitely possible, distlib's approach is
>> not backward-compatible, as it means installing new versions of a
>
> Correct, because distlib does not support multiple installed ve
On Jul 18, 2013, at 7:37 PM, Vinay Sajip wrote:
>> I think the point is that people might be dependent on this functionality
>> and
>
>> changing it out from underneath them could break their world.
>
>
> I got the point that Daniel made, and my question was about *how* their world
> would
On Tue, Jul 16, 2013 at 8:23 AM, Paul Moore wrote:
>
> On 16 July 2013 12:42, Oscar Benjamin wrote:
>>
>> I thought that 64 bit Windows could run 32 bit Windows .exe files
>> (although I don't have a way to check this).
>
>
> Yes, but there are 32-bit and 64-bit exe wrappers, which I suspect is
>
On Jul 18, 2013, at 8:15 PM, Donald Stufft wrote:
> So can we please limit our scope? Let's start by fixing the stuff we have
> now, punting on fixing some other problems by using the existing tooling and
> then let's come back to the things we've punted once we've closed the loop on
> some o
On Jul 18, 2013, at 8:33 PM, Daniel Holth wrote:
> We might as well allow happy setuptools users to continue using
> setuptools. I don't care about making a pkg_resources console_scripts
> handler that does the same thing because we can just use the existing
> one. The more important contributio
On Thu, Jul 18, 2013 at 8:36 PM, Donald Stufft wrote:
>
> On Jul 18, 2013, at 8:33 PM, Daniel Holth wrote:
>
> We might as well allow happy setuptools users to continue using
> setuptools. I don't care about making a pkg_resources console_scripts
> handler that does the same thing because we can
On Thu, Jul 18, 2013 at 8:15 PM, Donald Stufft wrote:
>
> On Jul 18, 2013, at 7:37 PM, Vinay Sajip wrote:
>
>>> I think the point is that people might be dependent on this functionality
>>> and
>>
>>> changing it out from underneath them could break their world.
>>
>>
>> I got the point that Dan
> version of them. So, I don't think it's accurate to consider
> multi-version installation a totally new feature. (And AFAIK, the
> point of contention isn't that setuptools *supports* multi-version
> installation, it's that it's the *default* implementation.)
That distutils features could be
So we've recently seen a big resurgence in activity on improving Python
packaging. First off, thats good, hopefully thats why we are all here. That
said, I'm becoming worried about a possible lack of focus, and I know I'm not
the only one. There have been many ideas floated, and many PEPs either
On Jul 18, 2013, at 8:39 PM, Noah Kantrowitz wrote:
> So we've recently seen a big resurgence in activity on improving Python
> packaging. First off, thats good, hopefully thats why we are all here. That
> said, I'm becoming worried about a possible lack of focus, and I know I'm not
> the onl
On Jul 18, 2013, at 9:47 PM, Robert Collins wrote:
> I'm not too worried about whats in progress...
>
> I am worried about disruption when we rush things - e.g. the current
> broken state of setuptools+pip.
>
> -Rob
I'd argue that doing too much at once will lead to rushing things and other
On 19 July 2013 13:26, Donald Stufft wrote:
>
> On Jul 18, 2013, at 8:39 PM, Noah Kantrowitz wrote:
>
>> So we've recently seen a big resurgence in activity on improving Python
>> packaging. First off, thats good, hopefully thats why we are all here. That
>> said, I'm becoming worried about a p
We have a lot of initiatives going every which way at the moment, so I
figured it would be a good idea to get a common perception of what we
consider to be the important near term goals and a realistic timeline
for improving the packaging ecosystem (in particular, the timing
relative to the CPython
On 19 July 2013 09:37, Vinay Sajip wrote:
>> I think the point is that people might be dependent on this functionality and
>
>> changing it out from underneath them could break their world.
>
>
> I got the point that Daniel made, and my question was about *how* their world
> would break, and whet
On 19 July 2013 10:39, Noah Kantrowitz wrote:
> So we've recently seen a big resurgence in activity on improving Python
> packaging. First off, thats good, hopefully thats why we are all here. That
> said, I'm becoming worried about a possible lack of focus, and I know I'm not
> the only one.
If you're getting "ImportError: No module named setuptools" when using "pip
install --upgrade",
see here for an explanation and solution:
https://github.com/pypa/pip/issues/1064
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.or
On Jul 19, 2013, at 12:23 AM, Nick Coghlan wrote:
> I like the idea of switching to zc.buildout style entry points - it
> makes it easier to get pip to a point where "no setuptools" means "can
> only install from wheel files" rather than "can't install anything"
> (that way pip can install setup
On Jul 19, 2013, at 12:39 AM, Donald Stufft wrote:
>
> On Jul 19, 2013, at 12:23 AM, Nick Coghlan wrote:
>
>> I like the idea of switching to zc.buildout style entry points - it
>> makes it easier to get pip to a point where "no setuptools" means "can
>> only install from wheel files" rather
On 19 July 2013 14:06, Nick Coghlan wrote:
> Already done or very close to done (Yay!):
>
> * improved PyPI SSL support
> * setuptools/distribute merger
> * easy_install SSL verification
> * setuptools support for additional hashes beyond md5
> * pip 1.4 release with SSL verifi
78 matches
Mail list logo
