A pypi-based app store solution for platform specific installation
I was reading the pyinstaller thread and had this idea but didn't want to hijack. Maybe a wild idea, and very possible totally impractical or hopelessly complex, but: could the existing pypi infrastructure be leveraged into a set of platform-specific app stores? Maybe maybe we could make it as simple as a single line in a pyproject.toml file. Imagine if all the end user does is install the store, and clicks the link to the project app. The store takes care of the rest. The developer marks their package as an installable program to be published to the store, optionally specifying things like specific platforms if needed. All the project website does for users to install is provide a url to their app in the store. Very very rough idea of how it might work: a store app API would provide an installation GUI if desired, and the store would build the environment needed for installing the package and dependencies. Once the specified environment is built, pip would take care of installing the package as usual. If this is an awful idea feel free to just say so. I have given it no deep thought and do not have the expertise to even think through what would be needed to create such a thing.
On Fri, 20 Nov 2020 at 15:44, Ricky Teachey <ricky@teachey.org> wrote:
I was reading the pyinstaller thread and had this idea but didn't want to hijack.
Maybe a wild idea, and very possible totally impractical or hopelessly complex, but: could the existing pypi infrastructure be leveraged into a set of platform-specific app stores? Maybe maybe we could make it as simple as a single line in a pyproject.toml file.
It could be done, but I'm not sure what you are thinking of when you say "the existing PyPI infrastructure". Someone would have to write the store code (which maybe could be based on the existing Warehouse code, but should be a separate project). And I wouldn't assume that the donation of space and bandwidth that our existing CDN provides to PyPI would be extended to this as well, but whoever develops this could ask.
Like most ideas of this nature, it's pretty good actually - at least in a broad sense. But someone needs to implement it, and everyone currently involved in Python packaging is (a) a volunteer and (b) massively over-stretched. So suggestions like "we need to do X" are unlikely to happen. Suggestions like "I plan on doing X, do I have your blessing" are a different matter (you have mine, FWIW!) :-) Sorry, I hope that doesn't come across as negative. I genuinely don't mean it to. But most of the issues in Python packaging are at their root basically down to no-one having the time - so ideas on their own just add to the backlog. What we really lack is people willing to do the work to implement some of the ideas that are around. And that doesn't really need any sort of approval or support from the PyPA, just (unfortunately) a lot of work and effort... I get that you're saying it's not something you can do yourself. So I guess let's see if anyone wants to take it on :-) Paul
On Fri, Nov 20, 2020, 11:00 AM Paul Moore <p.f.moore@gmail.com> wrote:
I was thinking that the pypi website could potentially act as the "home" of the store and the index could provide the basis of the store index. But I guess now that you mention it there's not necessarily a very compelling reason to marry the idea to pypi. Aside from making it "official". My main thought is python could really use an easy story to tell for platform installable apps. Pypi and pip feels like it is almost already exactly what is needed in terms of an app store, it just doesn't yet have a way to install on platforms without a bunch of upfront work. An app store tied to pypi and pip might be able to totally remove that friction. I get that you're saying it's not something you can do yourself. So I
guess let's see if anyone wants to take it on :-)
Paul
Yeah I'm definitely not the guy. Only hope here was to inspire someone else.
setup.py:setup(project_urls=) can include URLs to the app store entries for the package; though other than displaying all project_urks, PyPI doesn't do anything special like show the App Store icon for URL values with specific key prefixes in project_urls. Here's an example of specifying multiple project_urls: https://github.com/pypa/sampleproject/blob/master/setup.py#L196-L201 Would there need to be a PEP to specify specific key prefixes? for e.g. - prefix, store name - stores:fdroid, F-Droid - stores:playstore, Google Play Store - stores:appleappstore, Apple App Store - please advise regarding (URI) keys and stores On Fri, Nov 20, 2020, 12:08 PM Ricky Teachey <ricky@teachey.org> wrote:
In some sense PyPI already is such a store, if you don’t mind launching applications from the command line. That said, using PyPI in this way is not necessarily useful even ignoring platforms where side-loading is frowned upon or even impossible. As a user of applications I don’t really care in what language an application is written in, I don’t wan to look in the Python App Store, or the C# App Store, I just wan to use application A. Russel Keith-MacKee has a PyCon talk about Black Swans that talks (amongst others) about the problem of app distribution in particular on systems that aren’t desktop systems. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
On Sat, 21 Nov 2020 at 09:30, Ronald Oussoren via Python-ideas <python-ideas@python.org> wrote:
Maybe a good solution could be if it was easy to put a Python-based application into something like the Microsoft Store. It would be useful if there was a library that could easily produce the appropriate format for that (I don't know if one already exists) with all dependencies bundled. -- Oscar
From "[Distutils] pip and missing shared system system library" https://mail.python.org/archives/list/distutils-sig@python.org/message/7TCZJ... :
To py2app, py2exe, and pyinstaller, I'd add conda constructor:
Constructor is a tool which allows constructing an installer for a
collection of conda packages. It solves needed packages using user-provided specifications, and bundles those packages. It can currently create 3 kinds of installers, which are best thought of as delivery vehicles for the bundled packages. There are shell installers, MacOS .pkg installers, and Windows .exe installers. Each of these will create an environment on the end user's system that contains the specs you provided, along with any necessary dependencies. These installers are similar to the Anaconda and Miniconda installers, and indeed constructor is used to create those installers.
https://github.com/conda/constructor https://docs.python-guide.org/shipping/freezing/#freezing-your-code could be updated On Tue, Nov 24, 2020, 9:29 PM Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
On Fri, 20 Nov 2020 at 15:44, Ricky Teachey <ricky@teachey.org> wrote:
I was reading the pyinstaller thread and had this idea but didn't want to hijack.
Maybe a wild idea, and very possible totally impractical or hopelessly complex, but: could the existing pypi infrastructure be leveraged into a set of platform-specific app stores? Maybe maybe we could make it as simple as a single line in a pyproject.toml file.
It could be done, but I'm not sure what you are thinking of when you say "the existing PyPI infrastructure". Someone would have to write the store code (which maybe could be based on the existing Warehouse code, but should be a separate project). And I wouldn't assume that the donation of space and bandwidth that our existing CDN provides to PyPI would be extended to this as well, but whoever develops this could ask.
Like most ideas of this nature, it's pretty good actually - at least in a broad sense. But someone needs to implement it, and everyone currently involved in Python packaging is (a) a volunteer and (b) massively over-stretched. So suggestions like "we need to do X" are unlikely to happen. Suggestions like "I plan on doing X, do I have your blessing" are a different matter (you have mine, FWIW!) :-) Sorry, I hope that doesn't come across as negative. I genuinely don't mean it to. But most of the issues in Python packaging are at their root basically down to no-one having the time - so ideas on their own just add to the backlog. What we really lack is people willing to do the work to implement some of the ideas that are around. And that doesn't really need any sort of approval or support from the PyPA, just (unfortunately) a lot of work and effort... I get that you're saying it's not something you can do yourself. So I guess let's see if anyone wants to take it on :-) Paul
On Fri, Nov 20, 2020, 11:00 AM Paul Moore <p.f.moore@gmail.com> wrote:
I was thinking that the pypi website could potentially act as the "home" of the store and the index could provide the basis of the store index. But I guess now that you mention it there's not necessarily a very compelling reason to marry the idea to pypi. Aside from making it "official". My main thought is python could really use an easy story to tell for platform installable apps. Pypi and pip feels like it is almost already exactly what is needed in terms of an app store, it just doesn't yet have a way to install on platforms without a bunch of upfront work. An app store tied to pypi and pip might be able to totally remove that friction. I get that you're saying it's not something you can do yourself. So I
guess let's see if anyone wants to take it on :-)
Paul
Yeah I'm definitely not the guy. Only hope here was to inspire someone else.
setup.py:setup(project_urls=) can include URLs to the app store entries for the package; though other than displaying all project_urks, PyPI doesn't do anything special like show the App Store icon for URL values with specific key prefixes in project_urls. Here's an example of specifying multiple project_urls: https://github.com/pypa/sampleproject/blob/master/setup.py#L196-L201 Would there need to be a PEP to specify specific key prefixes? for e.g. - prefix, store name - stores:fdroid, F-Droid - stores:playstore, Google Play Store - stores:appleappstore, Apple App Store - please advise regarding (URI) keys and stores On Fri, Nov 20, 2020, 12:08 PM Ricky Teachey <ricky@teachey.org> wrote:
In some sense PyPI already is such a store, if you don’t mind launching applications from the command line. That said, using PyPI in this way is not necessarily useful even ignoring platforms where side-loading is frowned upon or even impossible. As a user of applications I don’t really care in what language an application is written in, I don’t wan to look in the Python App Store, or the C# App Store, I just wan to use application A. Russel Keith-MacKee has a PyCon talk about Black Swans that talks (amongst others) about the problem of app distribution in particular on systems that aren’t desktop systems. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/
On Sat, 21 Nov 2020 at 09:30, Ronald Oussoren via Python-ideas <python-ideas@python.org> wrote:
Maybe a good solution could be if it was easy to put a Python-based application into something like the Microsoft Store. It would be useful if there was a library that could easily produce the appropriate format for that (I don't know if one already exists) with all dependencies bundled. -- Oscar
From "[Distutils] pip and missing shared system system library" https://mail.python.org/archives/list/distutils-sig@python.org/message/7TCZJ... :
To py2app, py2exe, and pyinstaller, I'd add conda constructor:
Constructor is a tool which allows constructing an installer for a
collection of conda packages. It solves needed packages using user-provided specifications, and bundles those packages. It can currently create 3 kinds of installers, which are best thought of as delivery vehicles for the bundled packages. There are shell installers, MacOS .pkg installers, and Windows .exe installers. Each of these will create an environment on the end user's system that contains the specs you provided, along with any necessary dependencies. These installers are similar to the Anaconda and Miniconda installers, and indeed constructor is used to create those installers.
https://github.com/conda/constructor https://docs.python-guide.org/shipping/freezing/#freezing-your-code could be updated On Tue, Nov 24, 2020, 9:29 PM Oscar Benjamin <oscar.j.benjamin@gmail.com> wrote:
participants (5)
-
Oscar Benjamin -
Paul Moore -
Ricky Teachey -
Ronald Oussoren -
Wes Turner