powerpill reborn: pacman wrapper for faster downloads

Xyne · 2020-12-13 16:23:37

I'll gladly change all of my launcher scripts to use best practices. I appreciate having this shortcoming pointed out, but I would appreciate it even more without the snark. I get that it's part of your personality, but it's irksome and unnecessary. Rather than assume all of the mistakes in someone else's code are due to deliberate disregard for various standards, try assuming that maybe, just maybe, those choices were made, possibly a long time ago, based on limited knowledge or before current best practices were established. Many such vestiges persist until attention is brought to them, as is the case here.

As for installing "command line tools" as modules, they are actually used as modules by other packages. If you have further suggestions to make without the layer of unmistakable disdain, please feel free to share.

eschwartz · 2020-12-13 18:22:03

Setuptools entry points are a nice-to-have, but not everyone needs, wants, or uses them (especially if your code is not on PyPI and you don't distribute via any PyPA method).

There's no specific standard to point at for "don't use bash just to execute python immediately, when just using python in the first place would do equally well", but it would be simpler and introduce fewer moving parts to write a python script in /usr/bin rather than a bash script...
(It would also avoid the --help text printing the module name, e.g. "usage: Reflector.py", and instead print the script name, "usage: reflector". argparse can't know that it was launched from "/usr/bin/reflector" if all it sees is "python3 -m Reflector" running "/usr/lib/python3.9/site-packages/Reflector.py" as a module)

It's the same reason why we don't install "cp" to /usr/lib/coreutils/cp and create a /usr/bin/cp wrapper script:

#!/bin/bash

cp "$@"

Xyne wrote:

Rather than assume all of the mistakes in someone else's code are due to deliberate disregard for various standards

Speaking of "best practices", how is the migration from tarballs to some form of version control system (e.g. git) as was promised in 2011 and again in 2015 coming along? IIRC the last news on the subject was "undefined concerns about git".
I dislike working with or looking at code where anything other than the latest version disappears (and occasionally not even that is available, so the AUR package cannot build) and it's impossible to see the differences between versions unless you have meticulously maintained local copies of a berjillion tarballs, and even then, fairly awkwardly due to the need to extract and run `diff` repeatedly between versions. Even the https://xyne.archlinux.ca/projects/powerpill/#changelog is unmaintained for the last 5 years, as it still claims the latest version is 2016-01-15!

Your stuff is a bit of a black box, and it's inconvenient to read or reason about the code in order to offer improvements. You seem to prefer it that way. For all I know, bash entry points is more of the same. I mostly stopped caring or using, years ago. (I think this was mostly due to the disappointment about refusing to use version control, and partly due to getting sick and tired of trying to fill in the blanks from the changelogs by diffing tarballs.)

I don't know where it might be getting used as a module vs. a script, but mea culpa -- I shouldn't have assumed that in particular.

eschwartz · 2020-12-13 18:22:35

https://python-packaging.readthedocs.io … ripts.html

The distutils approach:
https://docs.python.org/3/distutils/set … ng-scripts

The setuptools approach:
https://setuptools.readthedocs.io/en/la … point.html

The distutils script approach is probably fine, it just handles the "best practice" of taking your arbitrary script and installing it with shebang fixups, as part of setup.py install rather than manually "install -Dm755 src dest".

The setuptools entry point would let you declare it all in setup.py and drop a file from the sources (take a look at e.g. /usr/bin/pip to see the script it generates), but add a build dependency on setuptools. (Very recent setuptools versions use importlib.metadata if available, rather than needing a runtime dependency on setuptools too.)
OTOH, using setuptools would correctly handle Windows, where you need to have a .exe because that's how Windows rolls... which would matter so much more if your Arch-centric software was ever expected to run from Windows cmd.exe... still useful knowledge in case you decide to write interesting cross-platform programs that do, in fact, need to run on Windows.

Last edited by eschwartz (2020-12-13 18:23:30)

FirstAirBender · 2020-12-13 20:55:12

Xyne wrote:

I'll gladly change all of my launcher scripts to use best practices.

Awesome!

Xyne · 2020-12-13 23:14:52

eschwartz wrote:

https://python-packaging.readthedocs.io … ripts.html
The distutils approach:
https://docs.python.org/3/distutils/set … ng-scripts
The setuptools approach:
https://setuptools.readthedocs.io/en/la … point.html
The distutils script approach is probably fine, it just handles the "best practice" of taking your arbitrary script and installing it with shebang fixups, as part of setup.py install rather than manually "install -Dm755 src dest".
The setuptools entry point would let you declare it all in setup.py and drop a file from the sources (take a look at e.g. /usr/bin/pip to see the script it generates), but add a build dependency on setuptools. (Very recent setuptools versions use importlib.metadata if available, rather than needing a runtime dependency on setuptools too.)
OTOH, using setuptools would correctly handle Windows, where you need to have a .exe because that's how Windows rolls... which would matter so much more if your Arch-centric software was ever expected to run from Windows cmd.exe... still useful knowledge in case you decide to write interesting cross-platform programs that do, in fact, need to run on Windows.

Thanks.

edit
The powerpill executable has been switched to a distutils script and will be uploaded shortly. I'll convert all of the other packages as I update them.

Last edited by Xyne (2020-12-13 23:53:33)

Arch Linux

#301 2020-12-13 16:23:37

Re: powerpill reborn: pacman wrapper for faster downloads

#302 2020-12-13 18:22:03

Re: powerpill reborn: pacman wrapper for faster downloads

#303 2020-12-13 18:22:35

Re: powerpill reborn: pacman wrapper for faster downloads

#304 2020-12-13 20:55:12

Re: powerpill reborn: pacman wrapper for faster downloads

#305 2020-12-13 23:14:52

Re: powerpill reborn: pacman wrapper for faster downloads

Board footer