On 13 April 2015 at 12:56, Chris Barker <[email protected]> wrote: > Which brings me back to the question: should the python tools (i.e. wheel) > be extended to support more use-cases, specifically non-python dependencies? > Or do we just figure that that's a problem better solved by projects with a > larger scope (i.e. rpm, deb, conda, canopy). > > I'm on the fence here. I mostly care about Python, and I think we're pretty > darn close with allowing wheel to support the non-python dependencies, which > would allow us all to "simply pip install" pretty much anything -- that > would be cool. But maybe it's a bit of a slippery slope, and if we go there, > we'll end up re-writing conda.
The main two language independent solutions I've identified for this general "user level package management" problem in the Fedora Environments & Stacks context (https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement) are conda (http://conda.pydata.org/) and Nix (https://nixos.org/nix/about.html), backed up by Pulp for plugin-based format independent repository management (http://www.pulpproject.org/). >From a Python upstream perspective, Nix falls a long way behind conda due to the fact that Nix currently relies on Cygwin for Windows support - it's interesting to me for Fedora because Nix ticks a lot of boxes from a system administrator perspective that conda doesn't (in particular, system administrators can more easily track what users have installed, and ensure that packages are updated appropriately in the face of security updates in dependencies). I definitely see value in Python upstream formats being able to bundle additional files like config files, desktop integration files, service definition files, statically linked extensions modules, etc, in a way that not only supports direct installation onto end user machines, but also conversion into platform specific formats (whether that platform is an operating system, or a cross-platform platform like nix, canopy or conda). The point where I draw the line is supporting *dynamic* linking between modules - that's the capability I view as defining the boundary between "enabling an addon ecosystem for a programming language runtime" and "providing a comprehensive software development platform" :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
