You are not logged in.

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

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 6,581
Website

Re: powerpill reborn: pacman wrapper for faster downloads

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.


My Arch Linux StuffForum EtiquetteCommunity Ethos - Arch is not for everyone

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,870

Re: powerpill reborn: pacman wrapper for faster downloads

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? tongue 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.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

eschwartz
Trusted User/Bug Wrangler
Registered: 2014-08-08
Posts: 3,870

Re: powerpill reborn: pacman wrapper for faster downloads

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)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

FirstAirBender
Member
Registered: 2019-09-13
Posts: 10

Re: powerpill reborn: pacman wrapper for faster downloads

Xyne wrote:

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

Awesome!

Offline

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

Xyne
Moderator/TU
Registered: 2008-08-03
Posts: 6,581
Website

Re: powerpill reborn: pacman wrapper for faster downloads

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)


My Arch Linux StuffForum EtiquetteCommunity Ethos - Arch is not for everyone

Offline

Board footer

Powered by FluxBB