Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Nick Coghlan
On 19 August 2016 at 15:32, wrote: > From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- >> Alternatively, we could simply not worry about a user level flag, and >> just have a project level flag that's set to "No legacy formats" by >> default for new projects - new users won't have any in

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread tritium-list
> -Original Message- > From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- > list=sdamon@python.org] On Behalf Of Nick Coghlan > Sent: Thursday, August 18, 2016 9:40 PM > To: Nathaniel Smith > Cc: DistUtils mailing list > Subject: Re: [Distutils] Deprecating little used file

Re: [Distutils] Future of setuptools and buildout

2016-08-18 Thread Wes Turner
On Thu, Aug 18, 2016 at 4:54 PM, Chris Barker wrote: > On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth wrote: > >> And a while back I argued against setuptools-lite, because I thought it >> would not solve the poor extensibility problem that stems from its basic >> distutils derived design... whic

Re: [Distutils] Future of setuptools and buildout

2016-08-18 Thread Wes Turner
Re: buildout and pip and wheel "Add support for installing wheels" https://github.com/buildout/buildout/issues/144 It's been awhile since I've worked with buildout (for Zope 2, Plone, AppEngine zipimports). This reads #egg= links from pip requirements files: - https://github.com/collective/coll

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Nick Coghlan
On 19 August 2016 at 08:12, Nathaniel Smith wrote: > On Mon, Aug 15, 2016 at 5:02 PM, Nick Coghlan wrote: >> * new project by existing maintainer: here, I'd be inclined to flag >> maintainer accounts at the start of the deprecation period based on whether >> or not they're currently using the le

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Nick Coghlan
On 19 August 2016 at 07:58, Donald Stufft wrote: >> On Aug 18, 2016, at 5:53 PM, Barry Warsaw wrote: >> I'm very sure I don't understand something, because I thought wheels were >> just >> fine for the import-from-sys.path use case. I mean, pip does this and in >> Debian, we have a program (dir

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Nathaniel Smith
On Mon, Aug 15, 2016 at 5:02 PM, Nick Coghlan wrote: > * new project by existing maintainer: here, I'd be inclined to flag > maintainer accounts at the start of the deprecation period based on whether > or not they're currently using the legacy formats on any of their projects - > that is, the mi

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Nathaniel Smith
On Tue, Aug 16, 2016 at 10:21 PM, Nick Coghlan wrote: > On 17 August 2016 at 01:15, Leonardo Rochael Almeida > wrote: >> PS: In the buildout community, we never really understood the impetus for >> replacing egg as a format, which is really not all that complex and not all >> the different from w

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Barry Warsaw
On Aug 17, 2016, at 03:21 PM, Nick Coghlan wrote: >This means that the situation we've managed to get to now is that we >have wheels as a satisfactory replacement for the "binary >distribution" use case, but we haven't even *tried* to replace eggs >for the "standalone path entry" use case. I'm ve

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

2016-08-18 Thread Donald Stufft
> On Aug 18, 2016, at 5:53 PM, Barry Warsaw wrote: > > On Aug 17, 2016, at 03:21 PM, Nick Coghlan wrote: > >> This means that the situation we've managed to get to now is that we >> have wheels as a satisfactory replacement for the "binary >> distribution" use case, but we haven't even *tried*

Re: [Distutils] Future of setuptools and buildout

2016-08-18 Thread Chris Barker
On Wed, Aug 17, 2016 at 6:45 PM, Daniel Holth wrote: > And a while back I argued against setuptools-lite, because I thought it > would not solve the poor extensibility problem that stems from its basic > distutils derived design... which includes all the classes and subclasses > that have to work