Just to throw a further spanner in the works, I think there are at least three different cases hiding under the banner of ‘applications’. I’m not trying to split hairs or make more work here - these really seem as different from each other as from libraries:
Command line applications: our main library-focused tooling, with entry points and the addition of pipx, mostly works pretty well for these (I’m not saying it’s all perfect, but…).
(Web)server applications: You’re usually deploying these rather than distributing them for end users to install. I think the people working on these have found decent ways to work with Python packaging tools, like pinning dependencies in a requirements.txt file.
GUI applications: Our normal packaging tools really don’t help much here, and there’s a small constellation of alternative tools aimed at this. It’s particularly complicated because things like installers and shortcuts are quite different between Windows, Mac and Linux.
I agree entirely, and I wasn’t trying to suggest that there would have to be a single approach. In fact, I’ll add another case:
Data analysis (or similar) projects: where the “deliverable” is some sort of document, not an executable, and the Python code is part of the build process rather than the final product.
It’s maybe a stretch calling that an “application”, but it’s an important use case, and one that I certainly don’t think we provide much support for.
Yup, certainly - my day job is in this sort of sphere. Although I’d say the code itself is frequently part of the product, not just a build step - between things like tutorials and the drive for reproducible research, you often want to give people code they can execute themselves. But I guess you knew this, or you wouldn’t be talking about it in the context of Python packaging anyway.
I usually argue that this is an instance of using a deployed application. So the user might install Jupyter+libs as an application, and then simply use it to produce their deliverable.
Where it gets interesting is reproducibility, which is basically that user moving from using an application into deploying their own application. Personally I think it’s fine to leave this to the application (whether Jupyter or something else) to help with, and as long as our tools are good enough building blocks for them to use, we don’t have to solve it entirely.
Thank you to everyone who has participated in this thread. Based on feedback I have received in other threads, I intend to summarise all the strategy threads in one document or some other format. This document will be shared with the community once it is ready. Hopefully this document will help inform our next steps.
