Converge project/tool settings to pyproject.toml [5.x]

[CarliJoy]

Describe your use-case

There is a deciated isort.cfg file but no other tool (besides pre-commit) has its one config file, thats confusing.

Also isort.cfg only get added if --pre-commit is used.

Describe the solution you would like to see for your use-case

Add the isort.cfg into pyproject.toml or setup.cfg (both possible according to https://pycqa.github.io/isort/docs/configuration/config_files/)

Then it would be also okay (IMO) to include the settings by default in the pyproject.toml because they are related to the other tools (black for instance) used by the template.

IMO that would be the best and easiest solution:

• remove the isort.cfg and move the content to the default pyproject.toml

[CarliJoy]

I could create a PR if I you are okay with the procedure @FlorianWilhelm

[abravalheri]

Hi @CarliJoy, thank you for bringing this discussion forward. I agree with you that the way things are right now is definitely not the most "uniform" or "ideal" way of doing things, however I would argue that it is the more pragmatic 😝

For the version 4, I think we are still committing to provide people a escape hatch from isolated builds so they can still do some old fashion packages while things are not stable enough (via --no-pyproject). In that case, working conditionally with the flags and trying to assertively position the configuration for isort would result (in my opinion) in added complexity.

We could also try other alternatives like using setup.cfg or tox.ini, but then the future of these files are uncertain...

By the way, we do have some individual files for other tools like tox.ini, .coveragerc, .travis.yml, .cirrus.yml. Do you think .isort.cfg is particularly confusing?

[FlorianWilhelm]

@abravalheri, there was a long conversation in #256 about including pyproject.toml and I see that there are still some difficulties with it which is why not all options of setup.cfg are moved over. But is it correct that just adding pyproject.toml in a minimum way also doesn't hurt and allows upgrading gradually as it becomes more stable?

I would just want to challenge if a --no-pyproject flag really still makes sense as it increases the number of test cases and things that might go wrong a lot.

[abravalheri]

Hi @FlorianWilhelm, to be sincere, it is hard to judge if this is necessary or not.

Something that is interesting to note is the tone of setuptools official docs when mention PEP 517: it sounds like it is still something new and not universal, and therefore something to be careful about:

As PEP 517 is new, support is not universal, and frontends that do support it may still have bugs. For compatibility, you may want to put a setup.py file containing only a setuptools.setup() invocation.
(https://setuptools.readthedocs.io/en/latest/setuptools.html)

I completely agree though that it brings some extra complexity for testing, and that is usually why keeping the files separate help a bit. But yes, if PyScaffold community sees this extension as not needed any more, I would be more than happy to remove code (the most satisfying thing in maintaining an open source project is removing code no longer needed).

[FlorianWilhelm]

Hi @abravalheri, I think one can still have an editable install with python setup.py develop, right? So there is a perfect workaround and one could just mention this in the docs. You mentioned once that a lot of projects are moving towards pyproject.toml, and as also many people asked about it, the time might be ripe to also adapt it (with this little caveat that can be easily worked around).

Totally agree that deleting code that is no longer needed is one of those guilty pleasures every experienced programmer loves :-)

[julie777]

I turned my project directory into an editable install with pip -e .

[CarliJoy]

Well .coveragerc should be included to pyproject.toml as well (it can be)

travis, cirrus and kind of also tox are more CI tools so I kind of expect them to have their own files.

[abravalheri]

Thanks @CarliJoy I agree with you. I just wonder if we should do it right now, or wait a little bit more (in a future release) when things have settled down (e.g. when setuptools adopt PEP 621) and then we move all the configuration to pyproject.toml

[abravalheri]

After digesting a little bit more the discussion, I think we can have 2 approaches here:

1. We adopt a more conservative approach and keep things as they are for the time being until setuptools fully commit to pyproject.toml. There will be some work needed when that happen (I suppose next year before march since PEP 621 was accepted as provisional until then: https://discuss.python.org/t/pep-621-round-3/5472/109) and then we make sure to use pyproject.toml as much as possible, including the configurations of coverage and isort -- releasing v5.

• The pro of this approach is that we don't have much re-work to do for v4, we can release it relatively soon after this Christmas sprint is over :) (btw, thank you guys very much for the help on that).
• During v4, the configuration for PyScaffold should stay in setup.cfg and the user configuration file in $HOME/.config/pyscaffold should still be a .cfg file which is a sub-set of setup.cfg. For v5, we include PyScaffold configurations in pyproject.toml and the file in $HOME/.config/pyscaffold becomes a subset of pyproject.toml. That should be fine, since this feature is marked as experimental, and we are already warning the users that this change will happen eventually.
• The con of this approach is that 2 major releases very close in time can be painful for the community. On top of that, everyone aggress that centralising configs is nice, and we won't have that until v5.

2. We antecipate setuptools and embrace pyproject.toml removing the escape hatch (--no-pyproject).

• We should then change the configuration for PyScaffold itself to use pyproject.toml and the config file $HOME/.config/pyscaffold
• The cons of this approach are: anticipating setuptools can be painful and we will have to keep 2 parsers around (cfg and toml files); the release of v4 will take longer since we need to review thoroughly PyScaffold's own configuration, and implement the changes.

What do you guys think?

[FlorianWilhelm]

I would be in favor of the conservative option 1. One thing I don't fully understand. Why wouldn't it be possible to just provide a minimal pyproject.toml as the current pyproject extension does and remove the escape hatch --no-pyproject to make things easier? In a transition from v4 to v5 one could then assume that there is already one. Also the docs would be easier, e.g. we would not need to write things like "If you have no pyproject.toml, just type pip install -e but if you have one please use python setup.py develop".

[CarliJoy]

@abravalheri I guess some things are mixed up here.
IMO pyproject.toml is not only a place to store packinging information but also tool configurations i.e. isort.

So my general question is: Why would I ever need the --no-pyproject switch if the setup.py and the setup.cfg will continue to exist anyway atm?
I never heard about any case in which the only existence of a pyproject.toml that is configured in for a minimum to get setuptools to work (like Pyscaffold actually does).
IMO PEP621 is to new to new to adopt for a tool like pyscaffold if even if it would been accepted just now. I am with you, that this is more

So my suggestion would be:

• Remove the --no-pyproject hatch as keeping it will increase the complexity of the code sooner or later for no reason
• Keep the setup.py and setup.cfg as PEP621 is no mature enough to remove them. Also some tools (most notably mypy and flake8) do not yet support pyproject.toml
• Move Configuration of tools to pyproject.toml if they support it (see https://github.com/carlosperate/awesome-pyproject/ for a list)
• Keep pyscaffold configuration in setup.cfg like described in Add pyproject.toml by default #256 due to the reasons discussed there

[julie777]

I assume you meant patch instead of hatch.

[abravalheri]

Hi @CarliJoy, @FlorianWilhelm , thank you for your feedback.

Something to have in mind is that the existence of a pyproject.toml file changes the way wheels and packages are built even if setup.py and setup.cfg exists (or at least that was the case some months ago when I researched this topic). It is like you are activating a "PEP 517 mode" by having the file in the project structure, the tools will behave in a different way, and that might surface incompatibilities.

One of the problems I found myself when working with both setup.{py,cfg} and pyproject.toml is that the algorithm for solving "build-time dependencies" is not very robust. If you need to specify minimum versions, a weird error can appear. The recommendation from the maintainers is to not use setup_requires in setup.cfg when you have a pyproject.toml... But there is a particular situation that you simply cannot avoid having the setup_requires: editable installs.

pip install -e . or python setup.py develop will not check for the packages in pyproject.toml [build-system] requires. If you need build time dependencies in an editable installation, the only way of doing it so far is to rely on setup.cfg setup_requires.

I apologise if my knowledge in this topic is outdated, it is been a few months that I checked, and the packaging ecosystem in Python is evolving very fast. You can follow the discussion in PyPA that led me to these conclusions in: pypa/pyproject-hooks#86.

[abravalheri]

This issue I faced when developing PyScaffold in the past + the fact that the maintainers of setuptools do not trust the current implementations of PEP517 and PEP518 enough to the point they would remove all the warning and caution recommendations from setuptools official docs, is what makes me think having --no-pyproject around can be handy.

But as long as we have documentation on how people can opt out of it, it should be perfectly fine to remove the extension.
It would be basically swapping the --no-pyproject extension by a new chunk in the docs explaining on how to do that manually...

[FlorianWilhelm]

Hm... that's a tough decision. If people who are not opting out, experience strange errors like what you describe @abravalheri, it's still a huge problem. How are other libraries solving this? If there is already some adoption of pyproject.toml, those projects must have found ways to work around that, right? Editable installs are extremely important, I couldn't live without them and I am surely not the only one, thus the question arises if we should have pyproject.toml rather as an experimental opt-in in v4 if it is so problematic. I am quite outdated when it comes to the current state of setuptools and PEP517 so sorry for being not much help.

[abravalheri]

The way I solved it myself was to avoid using version ranges for the build-time dependency that was generating errors, and trust that the build tool would get the latest available version, which is not ideal, but I did not have a very strong version requirement there (I was just explicitly listing the version I had tested)... Cython, as a more complicated library, do not use pyproject.toml yet.

Something to have in mind is that the error I had happened for the wheel package, which is a very special package, and therefore might have been receiving special treatment from the build tool (I don't know, but yet the maintainer recommendation was general, not only for wheel). If that is not the case, this error might appear when 2 build-time dependencies specify common sub-dependencies, and therefore require some sort of version unification.

With all of this in mind, I think it should be relatively an uncommon error, since it is common practice for tools included as build-time dependencies to vendorise its sub-dependencies.

[CarliJoy]

Hmm I actually never had troubles with pip install -e . but I do not create that many packages.
But as you mentioning problems with setuptools and wheels -> I remembered that I run into troubles sometimes, so I had to pip install -upgrade setuptools wheel in my virtual environment every time before something worked.

So actually this line is currently part of every CI pipeline I use.

Still I am not sure what exactly the problem is (like how to reproduce it).
The thing is pyproject.toml is around for quite a long time and well adopted in a lot of other projects. So if there would be a downer like disallowing pip install -e in certain condition there should be a bug report around (but question actually would be where...).

I will look into it, trying to crawl github for projects that use pyproject.toml that use setuptools with a specific version or to see how wide spread different build dependencies are common.
So @abravalheri. Do you think the problem you described is so uncommon that we could go the road I suggested (plus adding some documentation)?

Or do we need some more research?

[abravalheri]

Hi @CarliJoy and @FlorianWilhelm, I created a proof of concept PR implementing the changes discussed here: #353. Please feel free to have a look and comment (specially about the auxiliary documentation).

I noticed a few things, and I would like to know your opinion before keep working on the PR:

• The config for .coveragerc seems to be really extensive, and adding it to pyproject.toml might end up "cluttering" it a lot (actually that was also true for isort in the previous major version, before profile got introduced. Should we still move it anyway?
• Currently pyproject.toml is set up in a NO_OVERWRITE fashion, which means that any update via putup -u will not touch it. .isort.cfg on the other hand allows overwriting, which will bring the latest templates from PyScaffold. Should we change any of these?
• What should we do with people migrating from v3 (an existing .isort.cfg) to v4? Leave the 2 files? Delete the existing .isort.cfg?

[FlorianWilhelm]

Hi @abravalheri, thanks a lot for putting so much work into it! As long as we are only dipping our toe into pyproject.toml I would be rather conservative with moving configs there. I would rather put the .isort.cfg into setup.cfg for version 4.0 and then maybe in a version 5.0 start with complete adoption of pyproject.toml. An inconsistent split between some tools with configs in pyproject.toml and some in setup.cfg is rather not so good. Regarding .coveragerc one could also add it to setup.cfg. So eventually one would have one configuration file for everything.

The update question is really hard. In case .isort.cfg is moved to setup.cfg I would rather delete it and emit a warning.

[abravalheri]

Hi @FlorianWilhelm, that is a very interesting point and valid alternative. I have the impression, though, that keeping things in separated files make PyScaffold's job much more straight forward :P (we just configure the files to be no_overwrite and then the users have complete control using the standard --force and --update mechanism. If instead we want to use setup.cfg or pyproject.toml, then we have to start considering merging the existing file with the new configs and a bespoke --force and --update on top of that).

Another pro of leaving things as they are is that we don't have any extra headache thinking about how to update between setup.cfg and pyproject.toml or if we have to delete old files and etc...

Moreover I am not quite convinced that having lengthy tool-specific configuration on pyproject.toml is a nice thing (the example of .coveragerc is a good one for that: I almost never open .coveragerc, but I need to change things most of the time in setup.cfg, having coverage configs there, for me would mean "visual pollution"). But I understand that those things in the end of the day are a matter of personal preference.

(If we are happy with ditching completely --no-pyscaffold and with the replacement documentation for the "escape hatch", the commit 8bb4428 can be merged independently of centralising configs in setup.cfg or pyproject.toml)

[FlorianWilhelm]

Hi @abravalheri, many valid points especially update the fact that updating becomes easier if we have separate files. Looking at setup.cfg right now I see that we have besides the setuptools following configs in there:

• flake8
• sphinx
• devpi
• pytest
• pyscaffold
• mypy

external configs are:

• isort.cfg
• pre-commit-config.yaml
• coveragerc
• tox.ini

So what would be our rule of thumb if a configuration is rather an external file or included in setup.cfg (if possible)? Sorry for my mathematician mind, but I always strive for rules, which then help to keep things consistent. I like your idea of using the length of a configuration file to differentiate. So one rule could be: If the configuration file is lengthy it stays as a separate configuration like tox.ini, pre-commit-config.yaml or coveragerc. Using this rule of thumb one would then need to integrate isort.cfg in setup.cfg because it's even shorter as the pytest configuration, which is already included.

Another rule could be: If the config file is from an (internal) extension and thus can be deactivated, it stays in a separate config. This rule would also work but might be confusing for the users as it's rather an implementation detail of PyScaffold. Speaking about extensions, I wonder if pre-commit is nowadays that ubiquitous that we should just create the config files without asking the users? Even if a user doesn't want to use it, it's no problem when the configuration files are there but it's available if they later learn about its blessings.

So what do you think about:

1. Having a rule of thumb for config of a tool in setup.cfg vs. separate file
2. Make pre-commit a default

[CarliJoy]

Hey everbody,

thanks for the many thoughts.
I would suggest moving the discussion of "Make pre-commit a default" to a new thread to not mix to many things.
I created it already: #356

[CarliJoy]

About the question of moving stuff out of setup.cfg given of the "length" of the configuration I would like to raise some doubts.
Isn't the idea of the PyScaffold to create a standard package for users that they don't have to worry about and is focused about:

“There should be one– and preferably only one –obvious way to do it.”

?
Then how to this goes in Hand with the idea of having some files based on their length (or anything else) as extra files in the folder root and others included in setup.cfg ?
For me that is definitely not obvious...

The only options I see following this paradigm are:

1. Keep every configuration of every tool in a separate file
2. Include everything in one configuration file like setup.cfg

Of course I understand that for maintenance reasons it would be easier to have separate files but should be this the rule on which things are decided? It is a valid point but IMO deciding such things we should think more about the user perspective of the decision:

• What is a user expecting if they update their project with pyscaffold?
  • IMO: They should be provided with the best standard we can think of. Following the guiding principle cited.
• What if a user modified a file that would be overwritten by pyscaffold. What are the criteria that a file is overwritten, updated or kept?
  • Is there anything to define this in the documentation? If not it should be included IMO.
  • Sections in setup.cfg should/can be handelled like separate files if it comes to choose between overwrite, update or keep.
• What is impression of a user that does not know all the tools used by pscaffold if they see a folder that is scattered with a lot of configurations files?
  • In my company we had already some questions from end users if they can delete some files because the meaning of it was unclear to them. Having a lengthy setup.cfg is also not optimal but users are more careful removing thing there as it is evident that the file is important.
• How can a user update the configuration of their project? How to easily change things?
  • If we move a configuration file to another file it should be obvious given the tools documentation how to change things. This is not the case for tox.ini for me. Spending 15min I could not find a single example explaining how to integrate a tox.ini into a setup.cfg. Also the sections in a tox.ini clearly belong to a tox but in a setup.cfg this is unclear for me. Do I have to add tox: to every section belonging to tox? How will tox handle sections that exist as tox:section and section? Will it generally ignore everything without a tox: suffix?

So I would actually include isort.cfg and coveragerc to setup.cfg but leave pre-commit-config.yaml and also tox.ini out of the setup.cfg.

First of all because it is not possible to include the pre-commit-config.yaml into the setup.cfg as well as other CI files.
But why leave tox.ini out?
Because as CI scripts, tox is not only the configuration a single tool but it defines a pipeline of different tools to be called (or can be used as such). So for me tox is more like CI configuration file and not a simple single tool configuration file.

Using this we can also define a guiding principle that is (more or less) obvious: Every configuration of single tools goes in the setup.cfg but every configuration of tools calling other tools as their main task / creating pipelines have their own separate file. That's because their configuration tends to be lengthily and has to be updated probably project wise.

So for me touching only some questions that would be a way to go forward. We would have a more obvious rule on when to include things in setup.cfg and also would cover useability IMO.
What do you think?

[CarliJoy]

Sorry if my posts are bit confusing. I prefer oral discussions.
What do you think about creating a dudle to meet for a 60min discussion to figure the question out?
Simply give a thumbs up or down for the idea @abravalheri @FlorianWilhelm

[abravalheri]

Thank you very much @FlorianWilhelm and @CarliJoy for the feedback.

I agree that moving forward we need to come up with a rule of thumb for where to put the configuration files, and you guys did a really nice job in explaining some nice approaches. In my mind all the solutions presented make sense [a) short/stable/not-"deactivatable" configs go to setup.cfg while long/"opt-in" configs go to separated files OR b) standalone configs go to setup.cfg while "integrator" tools go to setup.cfg]. I suppose in the case of b having .coveragerc integrated to setup.cfg is a price to be paid for being able to do a text search in the file and find everything in a single place. I do like a a lot also because the maintenance and complexity of the code to make it happen looks small to me (and also it is very handy in the case of running putup --update --force . and using git checkout to retrieve old versions of modified config files).

However, I would like to propose to postpone this decision to v5. Right now, even if we do our best to centralise all the tools in a single place there will always be tools that accept only either setup.cfg or pyproject.toml, so I feel like we would have to spend double energy on that (specially having to come up with a migration strategy once PEP621 is adopted by setuptools).

As previously stated, this does not change the fact that we can merge 8bb4428 right now (or at least after fixing eventual bugs, regardless of the decision of the configurations).

[CarliJoy]

Actually the only tool I can think of that only supports pyproject.toml is black, which is unconfigured (for a good reason) with pyscaffold.
Therefore the choice move everything to setup.cfg seems save to me.

Once we are heading to v5 I would suggest to look for or write a converter from cfg to toml will be needed by then anyway.
I don't think it will be much of an effort as we talking of adding two files only to setup.cfg and once we did that, given we have the converter, a transition to the pyproject.toml will be easy as cake.

[abravalheri]

Yes @CarliJoy that would be the best. To be sincere TOML is quite easy to work with because it have a very consistent markup with rich composite data types. cfg files on the other hand are harder, because they don't offer complex data types, and require each configuration key to be processed in an ad-hoc manner, interpreting the values depending on the context.

Hopefully with PEP621 on the horizon maybe someone will start working on such converter and we can use it 😝

[abravalheri]

Issue to monitor the progress of setuptools: pypa/setuptools#2671

[abravalheri]

Useful summary of supported config files (maybe outdated?): https://blog.pilosus.org/posts/2019/12/26/python-third-party-tools-configuration/

[abravalheri]

Between the configs used by PyScaffold, currently the tools provide support to pyproject.toml are (28/Sep/2021):

• isort
• mypy
• pytest
• coverage

Tools that do now support configurations via pyproject.toml:

• flake8
• devpi
• setuptools (but we are waiting for it anyway before making any change)

(As previously discussed, I considered that CI-related tools such as tox and pre-commit can have their independent file).

[CarliJoy]

Which tools are still missing?
black (even so we do not configure it) is missing in the list.

[abravalheri]

Hi @CarliJoy, I think the list above is complete in the sense of tools PyScaffold configures/has plans to migrate to pyproject.toml, right?

As we have previously discussed, we don't plan to change pre-commit, tox or any CI (including cirrus, travis and gitlab currently supported).

I imagine that it will never be possible to change readthedocs.yml or environment.yml.

[CarliJoy]

Yep.

[abravalheri]

I have created the experimental ini2toml package that could help us with this...

It is possible to install it with pip install 'ini2toml[lite]', but the [full] version requires a patched version of the atoml library (there are instructions in the README to help with this process).

The tests/examples folder contain a few examples on how the translation between .ini/.cfg and .toml works (under some assumptions/guesses on how setuptools would adapt the configurations not included in PEP 621).

[FlorianWilhelm]

After the chat with @RonnyPfannschmidt, just as a note what the alternatives to setuptools are if its development would not proceed in adopting PEP660 and pyproject.toml for configuration:

• flit, no binary builds and no extension system, thus setuptools-scm is not possible with it (at least not in a clean way), uses pyproject.toml and has PEP660
• trompolim, no binary builds, automatic version detection from git repos and git archives similar to setuptools-scm, currently no PEP660, uses pyproject.toml
• poetry, mixture of building/packaging and environment management, thus hard to combine with conda/mamba; allows for plugins, thus something like setuptools-scm should work and was tried but never accomplished with setuptools-scm but there is now also a poetry-dynamic-versioning plugin, binary files are not officially supported it seems but there's an undocumented way according to Stackoverflow, uses pyproject.toml.
• gumby elf, quite early in its development but aiming to be also an alternative for setuptools + wheel.

[abravalheri]

With PEP 621 support in setuptools it should be easier to swap between different backends. (My next challenge would be PEP 660 :))

flit-scm seems to suggest that using [tool.setuptools_scm] write_to = ... directly is a way of achieving something similar to what we do nowadays. I requires an additional build step though (invoking setuptools-scm directly, that could be added to tox -e build).

I would be keen in giving a try to a --flit extension. Since most of the times people ask about setuptools in the Python Discourse there is always someone pushing towards flit, I imagine that their user base will grow over time...

[julie777]

A couple things to note about config files:

1. not all tools support config in the pyproject.toml file
2. it might not be a good idea to put a tool config in pyproject.toml for other reasons.
3. having separate config files for tools shouldn't be a big problem on systems that respect hidden dot files. (I know it can be ugly on windows, but the answer is to use bash.)

One example of the second reason is have pylint generate a config file with all the options. I find it very convenient to use, as it has all the options and descriptions. However, if I used multiple tools that had very large config files and merged it all into pyproject.toml things would get ugly in a hurry.

I also seem to remember reading that it was never the intent that pyproject.toml hold all tool configuration information, but rather it held the required information about the builds system being used. I'll have to look for the reference.

[CarliJoy]

Maintainability is much easier if all linting i.e. configuration is in one central file.
If you have a lot of projects, you simply can find and list all pyproject.toml files to ensure that they all follow your company or community linting guidlines.

Also you just ne one kind of parser to centrally edit them.

If you scatter around all the config files this becomes very hard. You think of a lot of configuration files, need different parsers.
Simply put a mess.

[FlorianWilhelm]

I tend to agree with the opinion of @CarliJoy. More and more projects seem to adopt pyproject.toml and especially for small configuration files (e.g. isort.cfg), it makes sense but maybe not for really large ones (like CI/CD configs, e.g. .cirrus.yml). So maybe again a compromise makes sense.

[abravalheri]

Based on what I see in repos nowadays, it seems that there is a trend of centralising everything on pyproject.toml and the arguments presented by Kound and Florian are compelling.

It seems to be the right thing to do moving forward (but leaving CI-related files - which include tox.in separated).

This is an example of what it would look like: #611

[julie777]

Another part of this topic just occurred to me.

Many editors run tools while editing via some sort of integration. I have been using vscode lately and it runs linting continuously and formatting when I save a file. I've used it mostly for a javascript project, so I don't have much knowledge about python tool integration. One thing about vscode tool integration is it allows some of the tools to be configured in vscode settings or in rcfiles for the tool. I always use the rcfile because I want to be able to run tools on the command line, such as in precommit.

Does anyone know if putting settings for tools in pyproject.toml has any affect on editor integration?
I would like to hope not, but we should at least consider it.

[FlorianWilhelm]

Good point, I also don't know but I would assume as pyproject.toml becomes one of the default places for your configs, tool developers will also consider it for configuration.

[abravalheri]

For those interested in seeing how the pyproject.toml file would look like, I created this experiment: #611.

flake8 configurations and devpi:upload are the only things left behind in the setup.cfg.

[julie777]

@abravalheri Nice!

I also did a devpi experiment. I really like the idea of doing a local only publish test, even before going to PyPI test.
That could possible even be an automated test.

[FlorianWilhelm]

To revive this thread and also with regard to version 5. There are more and more build systems out there and if we ever gonna drop setuptools for something else, we should evaluate at least PDM, Hatch, Poetry, PyFlow and Flit. For comments on Poetry and Flit see above and @RonnyPfannschmidt seems to be a proponent of Hatch. Also my colleague @zotroneneis looks into these tools right now, which is certainly very helpful to us. Are there any news about the development of setuptools @abravalheri? Maybe with respect to dropping setup.cfg completely in favour of pyproject.toml without any downsides?

[FlorianWilhelm]

Thanks @abravalheri for your points. Then conclusion seems to be unanimously that we should stick with setuptools first and pave the way towards only pyproject.toml in version 5 before we think about the integration of other tools like hatch.

Hopefully also the Python community starts to converge more towards a single solution for managing virtual environments in the coming years, so that we can integrate it in PyScaffold.

There is actually another tool in the back of my head for quite a while that I want to work on. If I have some time, I'll work on it and try hatch as setuptools replacement within PyScaffold (just for a test run) and also mkdocs instead of Sphinx. Just to evaluate those tools in a real use-case to see how they perform.

[CarliJoy]

From a user perspective I also would agree that keeping setuptools(_scm) is easier. Everything else is not established/generic enough.
I would wait until some other major projects adopted hatch (which seems to be the only alternativ, considering that flit is refusing scm style versioning).

[FlorianWilhelm]

@RonnyPfannschmidt, maybe I am missing the obvious, but how would you use setuptools_scm in conjunction with hatch? I have to use "dynamic" versioning in hatch and need to convice setuptools_scm to write the version information in the right format?

[RonnyPfannschmidt]

The hatch-vcs plugin integrates setuptools-scm

[FlorianWilhelm]

Ah, thanks!

[quattro]

Any updates on this? It would be nice to move away from the mixed use of setup.cfg and pyproject.toml to have -only- pyproject.toml