Re: [Distutils] Deprecating little used file types/extensions onPyPI?
We could also extend the py.exe launcher to resolve a matching Python install for a wheel and run pip to install it. Then double-clicking a wheel file would do something useful. Having a standard UI would be better, though non-trivial. Top-posted from my Windows Phone -Original Message- From: "Paul Moore" Sent: 8/23/2016 7:51 To: "Antoine Pitrou" Cc: "Distutils" Subject: Re: [Distutils] Deprecating little used file types/extensions onPyPI? On 23 August 2016 at 15:12, Antoine Pitrou wrote: > On Tue, 23 Aug 2016 10:36:35 +0100 > Paul Moore wrote: >> >> I don't see any sign of *anyone* working on a curated distribution for >> Windows along the lines of Linux distros or Homebrew. (Unless you >> count cross-platform stacks like conda, which IMO are a different >> scenario than "system" Python installs). > > Under Windows, there isn't much moral difference between a conda install > (really a Miniconda or Anaconda install) and a python.org Python > install. You can even install Anaconda or Miniconda system-wide. > > (Miniconda is a minimal install of Python + conda, while Anaconda is a > pretty large selection of packages in addition - though not the entire > official repo contents, and not counting community packages) Agreed - sorry, I was responding more to Nick's implication around "system" management of Python, conda already has a well-established management process, but AIUI, it's largely independent of PyPI/pip (although it interoperates with those). So in the context of Windows package managers, conda is no more relevant there than it is in relation to (say) rpm or deb. Realistically, though, I'd expect people wanting a Python stack on Windows to gravitate more and more towards distributions like Anaconda (maybe less so outside its core area of scientific use) with the remaining users sticking to the python.org builds and pip. However, I'm not that keen on continuing support for bdist_wininst and bdist_msi. I'd rather put the effort into making pip and wheels a compelling solution for such users. IMO, it already is for command line use (the more so as more hard to build packages start providing wheels). The place where pip falls down is for people who want to stick to a GUI. For those people, I believe Idle is likely to be getting an interface to pip, and I'd like to see other tools like PTVS and PyCharm get similar capabilities (if they don't have them already). That may mean exposing an interface to pip's install mechanisms that's better than "use subprocess to call pip", but we'd need some concrete use cases to work out the best form of such interfaces. On the matter of Chocolatey, it should be pretty trivial to create recipes for installing Python packages via pip. So I'd see pip+wheel as remaining the standard interface pretty much indefinitely. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecating little used file types/extensions onPyPI?
On 17 August 2016 at 23:23, Steve Dower wrote: > Do you mean like zipapp and *.pyz files? Pretty much, yeah, but with a more fleshed out workflow that accounts for dependency bundling as well - you'd have a relatively normal Python app with a setup.py and/or requirements.txt, but be able to readily package the whole thing up for distribution. This kind of thing is *possible* today if you already know what you're doing, and at least the AWS Lambda docs are pretty decent when it comes to describing how to make it work in their (non-zipapp) usage model: http://docs.aws.amazon.com/lambda/latest/dg/lambda-python-how-to-create-deployment-package.html (I haven't checked the Azure Compute Function docs, and Google Compute Function is currently JavaScript only) However, these kinds of approaches are nowhere near as well fleshed out from an automation perspective as traditional Linux web service deployment - note that there's no mention in the AWS Lambda docs of using a requirements file rather than individual dependency installations. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Deprecating little used file types/extensions onPyPI?
Do you mean like zipapp and *.pyz files? Top-posted from my Windows Phone -Original Message- From: "Nick Coghlan" Sent: 8/16/2016 22:42 To: "Leonardo Rochael Almeida" Cc: "distutils sig" Subject: Re: [Distutils] Deprecating little used file types/extensions onPyPI? On 17 August 2016 at 15:21, Nick Coghlan wrote: > While rebranding eggs (or a close derivative) as "pypath entries" > could help make them more self-explanatory (especially when it comes > to explaining how the zipped form differs from wheel files), doing so > wouldn't actually give us any more architectural flexibility in > practice than the last option. That said, if folks *did* want to go down this path, then an important use case to consider is "single archive applications" suitable for use in services like AWS Lambda and Azure Cloud Functions, where you get a language runtime to play with, but need to provide everything you want to run in that environment as a single pre-bundled archive. Similar problems also show up when building rich client applications for Windows, Mac OS X, Android and iOS. This means you want tooling that targets the direct dependency bundling model, rather than the runtime environment configuration model favoured by pip and virtualenv. So this particular challenge *shouldn't* be framed as just a backwards compatibility and migration concern for buildout et al - the "all inclusive application bundle" approach is still an important use case, even though it isn't the lowest common denominator cross-platform dependency specification, retrieval and installation problem handled by the default toolchain. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
