On 2020-05-06 11:24, Lumir Balhar wrote:
I've took a look and the new guidelines look good to me.
The only thing I am afraid of is that there is a lot of magic behind new
macros. Previously, macros were a way how to use standard Python
commands like "python3 setup.py build" without memorizing them and
without a fear that you forget an recommended/standard/important
command-line option.
The problem is that "setup.py" is not really the standard any more. It
only works with packages that use setuptools. Currently that's most of
them, but maintainers of setuptools are very unhappy with the monopoly.
But now, the macros are much more complex and
newcomers might not understand what is behind them. Moreover, given the
fact that some of them are MUST, we might be too strict there. It is, of
course, a matter of taste, but what if I simply prefer to list all my
runtime dependencies manually to have a comprehensive list which also
includes all the dependencies outside Python world?
How do you ensure that list stays in sync with upstream?
I mean, sometimes I like to implement the latest possibilities and
macros to test them and see how they can help me and sometimes I like to
use the old way, write everything explicitly/manually and don't use
automation.
Everything should be written explicitly, but in setup.py (or wherever
the build backend looks for this info). Why do you want to duplicate it
in the spec?
Do you have any concrete use cases? "Sometimes" is hard to reason about.
Are there any specific MUSTs you would change to SHOULDs?