
Hi folks. I'm new to the list and don't mean to impose, but I've been following some of the recent developments of the PyPA and I'm wondering if the unreasonable expectations I have for Python packaging are about to come true, or if there's a simple workaround to achieve some of these goals in the meantime. In building the Python 3 application I'm currently working on I have the end goal of supporting Windows users, Debian-based system users, and maybe Fedora users with installable distributions they can install without worrying about dependencies. I won't consider my packaging efforts to be successful if somebody using one of these systems has to manually install Python 3.4 or PyQt5 before they can install my application. Ultimately I'd also like to package my application as a standalone OS X app, but I don't have access to an OS X system right now. After some wrestling with cx_Freeze in Python 3.4 on Windows 7 in a VirtualBox machine, I've been able to put together a satisfactory Windows test distribution bundled with all its dependencies. setuptools will produce an rpm package, but I wouldn't know how to make sure the package depends on PyQt 5 and the QScintilla plugin for PyQt 5, so Fedora users can install my application without having to know they need these dependencies. I can't list PyQt5 or PyQt5.Qsci in the "install-requires" setuptools option because, as far as I understand, this option is only for listing packages that can be installed by pip. I have managed to set up a Debian packaging infrastructure such that I can build a Debian binary package with the command "dh --with python3 binary-indep", but I haven't figured out how to include an XDG menu entry in the package, and I consider this a deal-breaker. Of course, setuptools doesn't currently handle XDG menus at all. So my wish list for setuptools or a similar tool is: * Automated XDG menu entry generation * Some way to handle dependencies that can't be installed by pip * Automated generation of Debian binary packages good enough to be accepted into the repositories * Automated generation of rpm packages with all the right dependencies (For all I know this could exist already, but considering the way dependencies are currently handled by setuptools I really doubt it) * In a perfect universe, easy cross-building functionality, so I could produce a standalone Windows executable or an OS X app from the comfort of Xubuntu.

On 15 June 2014 10:25, lunasspecto@gmail.com <lunasspecto@gmail.com> wrote:
So my wish list for setuptools or a similar tool is:
*
Automated XDG menu entry generation
*
Some way to handle dependencies that can't be installed by pip
*
Automated generation of Debian binary packages good enough to be accepted into the repositories
*
Automated generation of rpm packages with all the right dependencies (For all I know this could exist already, but considering the way dependencies are currently handled by setuptools I really doubt it)
These are all dependent on having platform specific extensions in metadata 2.0 to allow the platform specific metadata tweaks to be added without needing to manually duplicate the upstream metadata. The main focus there at the moment is in getting the PEP 440 versioning spec to a releasable state (Donald Stufft has been working on ensuring that can be integrated sensibly into pip, and there's a major update to all the draft metadata 2.0 PEPs coming soon based on that work). Once 440 is resolved satisfactorily, the focus will shift to PEP 426 itself, along with the initial iteration of the "standard extensions" in 459. With install hooks postponed for the time being (in favour of the more general "required extension" mechanism) most of the open questions there are actually around PEP 440, although the proposed design of the "constraints" based install time integrity checking model will need review.
* In a perfect universe, easy cross-building functionality, so I could produce a standalone Windows executable or an OS X app from the comfort of Xubuntu.
A build farm integrated into PyPI is also on the wishlist, but behind the migration to Warehouse on the list of things to be worked on (it also depends on the improved handling of build dependencies that is part of the metadata 2.0 definition). Donald could provide a better update than I can in terms of the current status of the Warehouse migration, and the remaining blockers. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (2)
-
lunasspecto@gmail.com
-
Nick Coghlan