Delay setting default Configuration root

[GDYendell]

I have experienced the same issue reported in #691. This change is intended to fix it.

As far as I can tell, in projects where pyproject.toml is not in the root, pip install will not work without root (and relative_to) defined in the pyproject.toml, but if it is defined in pyproject.toml then python -m setuptools_scm will not work - it gives a duplicate keyword argument error:

▶ python -m setuptools_scm 
Traceback (most recent call last):
  File "/dls_sw/prod/tools/RHEL7-x86_64/Python3/3-7-2dls1/prefix/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/dls_sw/prod/tools/RHEL7-x86_64/Python3/3-7-2dls1/prefix/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/scratch/development/setuptools_scm/src/setuptools_scm/__main__.py", line 83, in <module>
    main()
  File "/scratch/development/setuptools_scm/src/setuptools_scm/__main__.py", line 18, in main
    config = Configuration.from_file(pyproject, root=root)
  File "/scratch/development/setuptools_scm/src/setuptools_scm/config.py", line 216, in from_file
    return cls(dist_name=dist_name, **section, **kwargs)
TypeError: type object got multiple values for keyword argument 'root'

The problem is that it falls back to the setting root to be the same directory as pyproject.toml if --root is not passed as an option and passes that into Configuration.from_file, so root appears in both **section and **kwargs in cls() call.

This change moves the setting of this default down into Configuration.from_file, so that it can check if it already has a root from the config file. The effect is that --root will supercede the config file, but if --root is not passed and it exists in the config file, it will use that (where currently it throws an error). The behaviour of using --root (or "." if it is not given) to search for the config file and to create the default Configuration is maintained.

Fixes #691

[RonnyPfannschmidt]

at first glance this looks good, i suspect the the new rootfinding fails in certain cases on windows due to drive differences

[baodrate]

FYI @GDYendell, I fixed the tests and added handling for a previously neglected edge case (root specified in pyproject.toml should be relative to config file). I made a PR against your branch here:

GDYendell#1

tests are passing. You can see the results on my fork:

https://github.com/qubidt/setuptools_scm/actions/runs/2191926795

[GDYendell]

Thanks @qubidt !

@RonnyPfannschmidt shall I merge, or perhaps just cherry pick, these additional changes or do you want to take a look at it separately first?

[RonnyPfannschmidt]

I just returned from a 2 week vacation and haven't gotten to this yet in detail

I like the general idea, but have to verify some details on how to integrate things (the details around creating config objects are quite more messy than I'd like and your changes made that even more apparent)

[baodrate]

@RonnyPfannschmidt any update on considering this PR or an alternative solution to the issue?

[RonnyPfannschmidt]

I'm currently just not able to commit as much time to setuptools _acm as I'd like to

[RonnyPfannschmidt]

i finally did the review, indeed when root is overridden, then it should be ignored/not passed down

the approach implemented here unfortunately is not entirely correct, but the deferring a a a concept is the right idea

[RonnyPfannschmidt]

i cant reiterate this for the next release, but this is the next change i will sort out

[RonnyPfannschmidt]

i started to recreate the behaviour starting with creating unitests for the cli - i hope i can complete that pr today,

[RonnyPfannschmidt]

closing in favor of #731 which was heavily inspired by this one, but also adds tests and a warning for root enforcement (cli root superseeding config root)

thanks for providing this initial version which greatly cut down the time i needed to understand the problem

[GDYendell]

Thanks @RonnyPfannschmidt ! ⭐