On 8 May 2016 at 04:15, Chris Barker <chris.bar...@noaa.gov> wrote: > On Sat, May 7, 2016 at 6:51 AM, Nick Coghlan <ncogh...@gmail.com> wrote: >> >> On 7 May 2016 01:55, "Chris Barker" <chris.bar...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
