Open jedie opened 9 years ago
A note about unix: the distributions typically curate their packages themselves, so projects don’t have to publish their own deb/rpm/etc.
Publishing an sdist and a windows wheel covers most of what project authors should do, if I’m not mistaken.
(I would ping Nick Coghlan but his name is not in the autocomplete list for mentions. @dstufft)
I never contribute one of my project to a Linux distributions. So i don't realy know. But IMHO it's very much more work compared to just register/upload to PyPi, isn't it?
Normal users doesn't know anything about sdist/wheels... Maybe they doesn't know anything about python... So that's not really enough ;)
The idea of a PyPI GUI front end has been kicking around for quite a while. The main problem is one of resources. Getting contributors for the CLI tools isn't that difficult, as that's something PyPA contributors need for their own use, so there's a relatively small amount of additional effort in making them broadly available to everyone. By contrast, not only is a GUI front end most needed by folks that aren't in a position to create it themselves, but writing and maintaining GUI applications also tends to be vastly more expensive in designer, developer and quality assurance time than writing and maintaining CLI applications.
More generally, providing a good user experience to non-technical users pretty much requires using the platform native tooling. Any bootstrapping step that requires learning a custom workflow that reveals to the end user that the application uses Python under the hood is too high a barrier to entry for a non-technical audience.
That means an approach more along the lines of pyqtdeploy (http://pyqt.sourceforge.net/Docs/pyqtdeploy/introduction.html), PyInstaller (http://www.pyinstaller.org/) or cx-freeze (http://cx-freeze.sourceforge.net/) is likely to prove better in the long run, as those aim to produce platform native standalone packages that can be managed using the system packaging tools.
The stub section at https://packaging.python.org/en/latest/deployment.html#application-bundles should ideally be expaned to cover some of these tools. The wiki page at https://wiki.python.org/moin/DistributionUtilities provides some pointers, but is not really actively maintained, so it has a tendency to go stale.
(For technical audiences, more options are available. Something like Twitter's PEX, for instance, can be useful in a managed environment like a company's systems: http://pex.readthedocs.org/en/latest/)
The problem with tools like PyInstaller, cx-freeze: on each platform it only makes an executable that runs on that platform. You need access to a Windows, Linux and Mac machine and you must build on each platform on every release...
In my PyPi-GUI solution: You need only to add a new release to PyPi: Just run ./setup.py sdist upload and this on Linux, Windows or Mac...
But PyPi-GUI itself must use PyInstaller or cx-freeze to provide the "initial" install. In my mind this "PyPi-GUI installer" will install Python, if not exists. Use virtualenv and pip for install/update a "End-User Program"
The Problem: I haven't use PyInstaller and cx-freeze, yet and i have only create GUIs in TkInter.
It's worth noting that while a worthy idea, this isn't an easy problem to solve. Platform vendors struggle to provide good developer and end user distribution and installation experiences for their own platforms - going for a cross platform deployment and installation solution for end users without the development resources of a platform vendor behind you poses formidable challenges.
As a development community, it already takes a significant amount of effort to provide a good developer focused experience (pip et al), as well as a scientist/data analyst focused experience (conda et al). Those efforts are driven by the traditional "scratch your own itch" model of open source development: folks donate their time to working on them because they need those tools themselves.
The hard part of getting a sustainable PyPI GUI effort together is going to be more a matter of figuring out where the associated collaborative community is going to be drawn from, rather than writing the code (although the latter won't be especially simple either). One possible path to go down would be to explore getting a basic PyPI+pip+(venv/virtualenv) front end integrated into IDLE, now that pip is being bundled with CPython, and PEP 434 allows the addition of new features to IDLE in CPython maintenance releases.
Agree with you...
One possible path to go down would be to explore getting a basic PyPI+pip+(venv/virtualenv) front end integrated into IDLE
PyCharm do this already ;)
If i have time, i will start to implement this idea...
@jedie like this https://github.com/perone/stallion ?
Stallion seems to be only a webbased viewer for PyPi. You can't say "Install package XY into a new virtualenv", isn't it?
...and outdated packages. But... does not install packages. I saw later. Sorry
Cross-linking related CPython issue: http://bugs.python.org/issue27051
The problem:
How to distribute a Python end user application to normal users for all platforms?
IMHO there exist no solution that works with a few man-power.
A project can currently to this:
IMHO only big projects with many man-power can so this, isn't it? Small projects can provide a more or less complicated README:
There is my self contained bootstrap solution: https://github.com/jedie/bootstrap_env But this is IMHO not really end user friendly, e.g: non-dev windows users...
The Idea:
So what's about a PyPi GUI program? This program must be easy to install themself. But then, it should be very easy to install End-User-Python-Application via a few clicks.
IMHO it should create a virtualenv, install the app via pip and created .desktop/windows-link files for easy startup...
I looked around and didn't find any PyPi-GUI out there...
Any suggestions?