andreafrancia
commented
3 years ago None of this is useful once installed, so why are they being installed on end-user machines?
Because I did not think it could be a problem. Until now the differentiation was test code -vs- tested code, the test code remains in the tests directory and the tested code in the trashcli directory.
For the scripts generator... as a matter of curiosity, why not use setuptools entry points which handle this for you?
I'm not sure, I need to invoke the executable in automatic tests and I want my automatic test able to run without any set-up procedure. Using setuptools will need to launch setup.py before automatic tests.
For the version bump code... wouldn't it make a lot more sense to include it directly in script/bump?
I don't know how to import an executable python file that does have a trailing ".py" in its name. I don't want rename script/bump to script/bump.py because I think the language for the implementation of the bump script should not leak outside the file content to the file name.
I will move this code to a new trashcli_support directory that will be not included in the distribution.
Thanks for your work in maintaining the ArchLinux package up-to-date.
eli-schwartz
Updating trash-cli, my release tooling warned me that some new distributable files got created, which I cannot figure out the purpose of.
In commit 836e5e34d7cbd2a416539974e5c0f624912ea860 some code used to build the setuptools /usr/bin scripts was moved into the trashcli site-packages module.
In commit 14eb08c24fed3bb812740745b85c40d612ef4967 some code was added which is used by script/bump to edit the trashcli/trash.py file.
None of this is useful once installed, so why are they being installed on end-user machines?