Add pyproject.toml by default #256
Comments
|
TBH, when I found this ticket I decided that pyscaffold is not for me. I wonder if there is a better maintained project layout generator for python, one that already adopted stuff like this. |
|
Currently, I have not much time working on PyScaffold in my spare time. Contributors and even maintainers are always welcome. |
|
Hi @FlorianWilhelm, I found out one of these days that adding Other then breaking some builds, it also might affect us a bit in terms of development. Particularly we have to avoid circular dependencies in the section. Do you think that this can affect the way we list the extensions as extra optional dependencies for PyScaffold? Should we remove the formal dependency in the extensions (leaving them implicit and only try catching I also saw recently that I was wondering, if there is any way to configure setuptools_scm entirely from the This simplifies a lot, speeds up the build and avoid the self-bootstrapping thing when building PyScaffold itself... Of course, we could go completely the other direction as well... Now that the API of My final doubt is, should we also move PyScaffold configs from |
|
Hi @abravalheri, thanks for looking into this. My gut feeling is that we should start simplifying things for Do you think with the new In general, I also wonder if the update feature of PyScaffold is really used that often. A lot of complexity in our code comes from it and I also guess it still has quite some bugs as we tested only a few most common combinations. For version 4.0 I would favor concentrating on the core functionality of PyScaffold, i.e. providing some project template with everything you need for some serious coding in a standard way. It would really be a major change and reorg of the current codebase. No more wrapping of |
|
Hi @FlorianWilhelm, I have question regarding setuptools_scm: how does the custom formatting you encoded inside PyScaffold differs from setuptools_scm default (guess-next-dev + node-and-date)? Is it too bad to just use the defaults or use one of the pre-sets (that can be written as plain strings in setup.cfg/pyproject.toml)? Right now on my terminal in PyScaffold, if I do: python setup.py --version # => 3.2.3.post0.dev37+ga37efb2
python -m setuptools_scm # => Guessed Version 3.2.4.dev37+ga37efb2And if I create an arbitrary tag: git tag -a v3.3a1-dev0 -m "Test"
python setup.py --version # => v3.3a1.dev0
python -m setuptools_scm # => Guessed Version 3.3a1.dev0So I see that PyScaffold keeps the old version and adds a Even if we adopt pyproject.toml by default we still will need to maintain both setup.py and setup.cfg. Editable installs require a setup.py and setuptools still do not support listing dependencies and entrypoints in the toml file. A few other comments 😝
|
|
btw, this post is quite nice: https://www.scivision.dev/pyproject-toml-vs-setup-py/ |
|
Hi Anderson, what I don't like about the default version guessing of So, in general, I find the Regarding your statement
Will this change in the near future? I am not sure if having a mixture of I agree with What I don't like about the update feature is the fact that we are checking what the old PyScaffold version was and then we have those migration rules that for instance change bits and pieces in |
|
Setuptools_scm already ships both support for pyproject.toml and post release version numbers, im happy to help with the details |
|
Hi @FlorianWilhelm, as @RonnyPfannschmidt pointed out we could also try the $ python -c 'from setuptools_scm import get_version; print(get_version(version_scheme="post-release"))'
3.2.3.post39+g7d412e9
$ python setup.py --version # PyScaffold
3.2.3.post0.dev39+g7d412e9Indeed it is not exactly the same thing. I suppose the way PyScaffold works right now all the non tagged versions are considered dev-only, while setuptools_scm post-release strategy would result in valid 'sub-minor' releases... We could settle for this middle ground, unless @RonnyPfannschmidt is open for a contribution of another strategy (something like A doubt: @FlorianWilhelm, is there any difference for PyScaffold's local scheme and setuptools_scm's node-and-date? I went through the code but couldn't figure it out... |
|
Regarding setuptools, I am sure that the team is working a lot for this integration to happen... It might take some time though, because they have to move carefully to not break the entire ecosystem... And they just "finished" documenting There is another detail... Once the editable installs issue is standardised to not depend on $ pip install -q pep517
$ mkdir dist
$ python -m pep517.build .So I believe we either keep |
|
We can find a way to use click, maybe some high-order functions could do the trick (never understood exactly how the custom classes in click work, do HOF is my default workaround). We should have a look on the PyInquirer for the interactive feature as well, super cool. For updates, we could only document the steps for migrating between the versions and remove automatic updates from old PyScaffolds that are not backward compatible, raising an error with the URL for the manual update once we detect a We can discuss those 2 topics in a different thread and keep this one for |
|
pypa/pip#8212 is hopefully the way towards no longer needing a setup.py for editable installs |
As discussed in pyscaffold#245 and pyscaffold#256.
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
|
@FlorianWilhelm I have implemented a proof of concept/reference in #290, more precisely the commit 334f0a4 for removing the build-time dependency on PyScaffold. Comments/reviews are welcome. My idea is to still keep I imagine that for v4 however we will want to import pyscaffoldext-pyproject into the core. We might also opt for embracing |
|
Wow, @abravalheri, that's a PR deleting a lot, I like it :-) |
|
No strong reason in particular, it is just that the ecosystem looks still messy to me and we lack documentation. But I can go for it. Question @FlorianWilhelm, if I have the chance to migrate the |
|
@abravalheri, thanks. What would you prefer with respect to |
|
@FlorianWilhelm, I feel that all the projects are moving config to At some point even setuptools might do that... So I believe sooner or later we will. But as you say it is much easier for us to not deal with it right now. My only regret is to add a config file (as in #289) which format is born practically "deprecated" (this config file is something I am really looking forward in PyScaffold 4). How about we postpone this until the is no other change to be made for PyScaffold 4? |
|
From the pytest perspective i can say that there are potential detail pitfalls for toml vs config parser, i strongly suggest to be extra careful |
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
As discussed in pyscaffold#256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
As discussed in #256, after pytest-runner was deprecated and removed, the only strong reason for having PyScaffold required during builds is to use setuptools_scm. Docs can easily be generated via Makefile (already created by default) or tox/nox (the new tox template already contains a task for the docs). A way of removing this dependency is by injecting setuptools_scm directly on the `setup.py` template. In the future something similar can be done for `pyproject.toml` (when it is generated by default). This change is an attempt of doing that. As a direct consequence, we also remove PyScaffold as a build-time dependency of itself, which makes things easier.
|
Support for pyproject.toml has finally landed on the v4.0.x branch (in the terms discussed in this issue). I will close this for now, we can open other issues for any missing bits. |
After giving this more thought I reached the conclusion that for the time being the best is to not put PyScaffold configuration in If PEP 621 gets accepted and when setuptools starts reading |
It seems that
pyproject.tomlis here to stay. Some tools likeblackalready use it to store its configurations. Thus every new project should have one with the content:The text was updated successfully, but these errors were encountered: