[reportlab-users] ReportLab 3.x packaging and deployment

[Andy Robinson]

Thanks very much.   It has been really hard getting an overview of this.

We'll have to do our best to build things "by the book" (that web page
at least) and just produce all the bdist_whatever outputs..

- Andy

On 14 January 2014 06:26, Marius Gedminas <marius at gedmin.as> wrote:

> On Mon, Jan 13, 2014 at 01:58:22PM +0000, Andy Robinson wrote:

>> On 13 January 2014 13:32, Marius Gedminas <marius at gedmin.as> wrote:

>> > I agree with it 100%.

>> >

>>

>> Here is my very naive understanding, from occasional attempts to

>> follow the sig over the years....

>>

>> 1. in the beginning there was distutils

>> 2. setuptools got popular, then got forked to distribute.  They are

>> now trying to merge into something new which will replace distutils

>> completely.  setuptools is the unified version

>> 3. Guido et al not want the "new improved technology" in Python itself

>> yet, because once it goes in, it's effectively frozen and can't be

>> improved further.  That's why distutils is still in the Python

>> distribution.  But at some point, "what evolves from setuptools" will

>> go into a future Python and replace distutils.

>>

>> Could you tell me if this is roughly correct?

>

> More or less.

>

> There were two efforts to replace distutils/setuptools: Tarek Ziade's

> distutils2/packaging work, which was bravely backwards-incompatible and

> was completely abandoned after a year or two, unsurprisingly.

>

> And now people are working on multiple PEPs for things like specifying

> metadata formats that can handle dependencies etc.  One of the PEPs is

> about bundling a pip installer with Python 3.4+.  Now that people are

> thinking about backwards-compatibility and gradual migration of the

> existing ecosystem, things are going smoother.

>

> The long-term plan is to get rid of setup.py entirely and instead have a

> declarative file (maybe setup.cfg) that can describe your package, and

> then separate build tools that can produce sdists and wheels out of this.

> It will take time (many years) for this to mature.

>

> At least that's my impression.

>

> Marius Gedminas

> --

> It is easier to optimize correct code than to correct optimized code.

>                 -- Bill Harlan

>

> _______________________________________________

> reportlab-users mailing list

> reportlab-users at lists2.reportlab.com

> http://two.pairlist.net/mailman/listinfo/reportlab-users

>




-- 
Andy Robinson
Managing Director
ReportLab Europe Ltd.
Thornton House, Thornton Road, Wimbledon, London SW19 4NG, UK
Tel +44-20-8405-6420