[Distutils] moving things forward (was: wheel including files it shouldn't)

[Nick Coghlan]

On 8 May 2016 at 04:15, Chris Barker <chris.barker at noaa.gov> wrote:
> On Sat, May 7, 2016 at 6:51 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 7 May 2016 01:55, "Chris Barker" <chris.barker at noaa.gov> wrote:
>> > So my point is about scope-creep -- if you want the PyPa tools to solve
>> > all these problems, then you are re-inventing conda -- better to simply
>> > adopt conda (or fork it and fix issues that I'm sure are there....)
>>
>> conda doesn't solve these problems either - it solves the *end user*
>> problem for data analysts (install the Python library they want to use),
>
> I really need to make this clear -- there is NOTHING "data analyst" specific
> about these problems -- they do come up more in the computational
> programming domain, but there are any number of other application that have
> the same problems (pyQT has come up in this conversation, yes?) -- and we're
> finding conda to be a good solution for our web development needs, too -- a
> conda environment  is kinda like a lighter-weight, platform independent
> docker container. And of course, there is more an more data analysis going
> on behind web services these days too -- any python developer is going to
> run into these issues eventually...

Aye, I know - conda was one of the systems I evaluated as a possible
general purpose tool for user level package management in Fedora and
derivatives (see
https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement#Directions_to_be_Explored
for details).

The problem with it is a practical one related to barriers to
adoption: to push any of the three systems I looked at, we'd face
significant challenges on the system administrator side (providing
capabilities comparable to what they're used to with RPMs) *and* on
the developer side (interoperating with the existing language specific
tooling for all of the language runtimes provided in Fedora).

Hence my comment about conda not currently solving *system integrator*
problems in the general case - it's fine as a platform for running
software *on top of* Fedora and for DIY integration within an
organisation, but as a tool for helping to *build Fedora*, it turned
out to introduce a whole slew of new problems (like needing to add
support to COPR/Koji/Pulp), without giving us any significant
capabilities that can't be addressed just as well by increasing the
level of automation in the upstream -> RPM pipeline and simplifying
the end user experience for container images.

However, the kinds of enhancements we're now considering upstream in
pip should improve things for conda users as well - just as some folks
in Fedora are exploring the feasibility of automatically rebuilding
the whole of PyPI as RPMs (twice, actually, anchored on
/usr/bin/python and /usr/bin/python3), it should eventually be
feasible to have the upstream->conda pipeline fully automated as well.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia