On Wed, May 20, 2015 at 3:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 21 May 2015 at 03:37, Chris Barker <chris.bar...@noaa.gov> wrote: > > As such, it _could_ play the role that pip+wheel (secondarily pypi) play > in > > the python ecosystem. > > In practice, it can't, as conda is entirely inappropriate as an input > format for yum/apt/enstaller/zc.buildout/pypm/MSI/etc. well, I'm making a strong distinction between a build system and a dependency management / install system. conda is not any kind of replacement for distutils / setuptools. (kind of how rpm doesn't replace configure and make. at all.) I'm still confused as to why pip plays as big a role in building as it seems to, but I guess I trust that there are reasons. Maybe it's only wheel that conda duplicates. But this is all irrelevent, because: Rather than being strictly technical, the reasons for this are mostly > political (and partially user experience related) Exactly. setuptools+pip+wheel is, and should be, the "official" python distribution system. When folks try anyway, > it mainly serves to alienate people using (or working on) other > integration platforms rather than achieving anything productive (hence > my comment about the "one package manager to rule them all" attitude > of some conda proponents, well, sorry if I've contributed to that -- but I guess for my part, there is a core frustration -- I have only so much time (not much), and I want to support multiple communities, -- and I simply can't do that without doing twice as much work. Duplication of effort may be inevitable, but it is still frustrating. That way, Python developers can focus on > learning one publication toolchain (anchored by pip & PyPI), while > users of integrated platforms can use the appropriate tools for their > platform. > That's all very nice, and it works great for packages that don't have any external dependencies, but if I'm trying to publish my python package, pip+wheel simply doesn't support what I need -- I can't use only one publication toolchain. And indeed, even if it did (with my vaporware better support for shared libs), that would be incompatible with conda, which does, in fact, support everything I need. conda doesn't bridge that gap for Python in the general case, as it is > itself an integrator tool managed independently of the PSF well that is a political/social issue. > and > designed to consume components from *multiple* language ecosystems and > make them available to end users in a common format. > not sure why that precludes it being used for python -- Python somehow HWAS to use a system that is only designed for Python? why? > Python's far too far down > the distutils->setuptools->pip path to be readily amenable to > alternatives agreed. this is the key point - it's gotten a bit blended in with teh technical issues, but that really is the key point. -- I'll shut up now :-) (at least about this) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
