-
- Notifications
You must be signed in to change notification settings - Fork 1.3k
Entrypoints in declarative config are now supported #2604
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| ``setup.cfg`` sections used by the ``pbr`` and ``d2to1`` packages. | ||
| | ||
| Namely: only metadata-related keys from ``metadata`` section are supported | ||
| (except for ``description-file``); keys from ``files``, ``entry_points`` | ||
| and ``backwards_compat`` are not supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this comment is pertinent to the "compatibility with distutils2-like" sections. Is the entry_points as implemented by setuptools declarative config compatible with pbr and d2to1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps better would be to just remove the considerations about pbr and d2to1 compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I saw your review the other day, but I have been pretty busy, and forgot to reply.
I do think the compatibility part is a bit confusing, especially because it is at the forefront of the page. I have been periodically coming to this page for years now, generally for a quick reminder of some syntax when in doubt, or to see if something previously unsupported got implemented. But only now, and because of your comment, do I realize this particular section was really about compatibility with other tools.
I don't know if it's just me, but when I come to setuptools' documentation, what I expect to find, before anything else, is documentation about setuptools, not other tools. So I am not sure that should be "front matter". Also, since the early days of the setuptools' support for declarative configuration, quite a bit of time has passed. Such matters were probably more of an issue then, than now (though I could be wrong on about that).
So maybe it is now time to revamp this section a bit ? I would keep the compatibility section about those other tools though, because it might still be relevant to some. But I would move it to the bottom of the page. Focus on setuptools' features first. A more comprehensive, independent, "migration" or "cross tool compatibility" section could prove useful, but I wouldn't feel competent enough to write it. I, for example, never used neither pbr nor d2to1.
I'd be glad to spend some time on this tomorrow, if you find that what I am suggesting makes any sense at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your instincts align with mine. Yes, moving that compatibility information into a secondary section makes sense. I too am not particularly familiar with those concerns, so don't have much to add. Thanks for the consideration.
babe926 to 6ba2807 Compare | @cansjt could you rebase this PR to make the CI green? It's failing since pip switched their master branch to main which is already fixed on setuptools@main so rebasing will fix it. |
| =========================== ========== ========== ===== === | ||
| feature setuptools distutils2 d2to1 pbr | ||
| =========================== ========== ========== ===== === | ||
| [metadata] description-file N Y Y Y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's
| [metadata] description-file N Y Y Y | |
| [metadata] description-file S Y Y Y |
because in setuptools you can do long_description = file: README.rst, CHANGELOG.rst to achieve the same outcome.
| feature setuptools distutils2 d2to1 pbr | ||
| =========================== ========== ========== ===== === | ||
| [metadata] description-file N Y Y Y | ||
| [files] N Y Y Y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's just in the [options] section:
| [files] N Y Y Y | |
| [files] S Y Y Y |
| FTR the docs builds fail because Python 3.7 is used in those envs and the new update of |
20b1cff to f5ca09c Compare | .. note:: | ||
| A version loaded using the ``file:`` directive must comply with PEP 440. | ||
| It is easy to accidentally put something other than a valid version | ||
| string in such a file, so validation is stricter in this case. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved this around because I find it was scattering into pieces informations about a single keyword and breaking the reading flow. Also, all those grey notes boxes aren't that pretty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, all those grey notes boxes aren't that pretty.
Honestly I can't wait for the theme to be switched to furo.
| in a dedicated subsection ``options.packages.find``. This subsection | ||
| accepts the same keys as the ``setuptools.find_packages`` and the | ||
| ``setuptools.find_namespace_packages`` function: | ||
| ``where``, ``include``, and ``exclude``. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above. Puts all informations about a particular keyword into one place.
f5ca09c to fcd2e6d Compare | ============================== ================= ================= =============== ======================= | ||
| name str | ||
| version attr:, file:, str 39.2.0 (1) | ||
| version attr:, file:, str 39.2.0 :ref:`(1)<note-meta-1>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you considered using footnotes? It should be easier to maintain them.
https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#footnotes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed it look better and would probably be easier to maintain. I am just wondering if some themes would move them all to the bottom of the page. That would leave an orphan notes paragraph behin.
But with the current one, they stay where they are defined.
4140483 to f051c1d Compare The documentation still states it is not though. Co-authored-by: Sviatoslav Sydorenko <wk.cvs.github@sydorenko.org.ua>
f051c1d to d339125 Compare | extras_require section [#opt-2]_ | ||
| python_requires str | ||
| entry_points file:, section | ||
| entry_points file:, section 51.0.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this 51? I thought I've been using this for years, well before 51 was even released? I could have sworn it at least works on 44. There's nothing in the 51 release notes that mentions this either. See wntrblm/nox#553.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this supposed to be 41 instead? That sounds about right.
The documentation still states it is not though.
Closes: #2603
Summary of changes
Removed inaccurate statement
Added an example of the now supported feature.
Closes
Pull Request Checklist
changelog.d/.(See documentation for details)