# Help testing experimental features in setuptools

**URL:** <https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821>\
**Category:** Packaging\
**Created:** [February 20, 2022, 7:48pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821 "2022-02-20T19:48:05Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 20, 2022, 7:48pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/1 "2022-02-20T19:48:06Z")

</div>

Hello all.

For the past months we have been experimenting with adding some features to setuptools, specially the support for project metadata in `pyproject.toml` (initially introduced in PEP 621).

Other features complement it: automatic layout discovery (for flat, src or single-module layouts), defaulting to `include_package_data=True`, etc… The idea is to make the `[tool.setuptools]` table in `pyproject.toml` not necessary that for the simple use cases.

If anyone is interested in helping testing these features in their packages, before they are merged on the `main` branch, it would be super helpful!

## How can you help?

If you have a project that uses setuptools, you can help by doing the tests bellow (or similar):

1. In your `pyproject.toml` you can try replacing `requires = ["setuptools",...]` with something similar to the following:

2. After doing the change in 1, you can try porting the metadata in your `setup.cfg` to `pyproject.toml` and running the build step again (`python -m build`).

3. If everything works correctly with tests 1 and 2, you can also experiment with the automatic discovery.  
Configurations like the following should be no longer necessary (so you can try removing them from `pyproject.toml`):

## _Please let me know if something breaks 😄_

### Notes

After each test, it might be a good idea to inspect the generated distribution archives:

```bash
unzip -l dist/*.whl
tar tf dist/*.tar.gz

```

For maximum isolation you can also try removing build/dist files between each test:

```bash
rm -rf build dist *.egg-info # or src/*.egg-info if you use the src-layout

```

There is a backward-incopatibility with the auto-discovery:

- The new implementation will consider implicit layouts by default (as in PEP 420), so if you have extra folders in your project root with Python files in them, you might see extra files in your generated wheel that were not there before.
- There are some rules in place to [exclude common directories](https://setuptools--2894.org.readthedocs.build/en/2894/userguide/package_discovery.html#automatic-discovery), e.g. `tools`, `examples`, but it will not cover everything.
- The way to solve this is by explicitly adding the correct parameters in `[tool.setuptools.packages.find]` or by renaming your extra folders as “private” folders (using a leading `_` or `.`, e.g. `experiments => _experiments`).

Currently there is very little documentation about this style of build in setuptools. That is the next step in my plan 😁

* * *

* * *

* * *

### Known issues/non-intuitive behaviour (not blocking)

1. `warning: check: missing required meta-data: url` - This warn happens if you don’t specify a `Homepage` in `project.url` (or `homepage`, `Home-page` etc…)  
The action point here is to make the warning message more specific.  
(I added some clarification about this in pypa/setuptools#3182. While the original warning will still appear, there is a preceding message specifically talking about `Homepage`)
2. `warning: check: missing meta-data: if 'author' supplied, 'author_email' should be supplied too` - see: [Prevent warn on false positive for author/maintainer's email by abravalheri · Pull Request #116 · pypa/distutils · GitHub](https://github.com/pypa/distutils/pull/116)
3. ~~Auto-discovery considers PEP 420 active by default (this is a desired/intentional behaviour), however this behaviour might be confusing for users using the flat-layout with non-conventional package structure.~~ (To be at the safe side, if more than one top-level package is discovered for the flat-layout, setuptools will now raise an exception: pypa/setuptools#3177)
4. ~~Missing docs (future work)~~ (There are _some_ docs now: pypa/setuptools#3172)

* * *

### Existing `setuptools` issues/limitations/non intuitive behaviour (not related to this change)

1. When using `tool.packages.find.exclude` sub-packages don’t get automatically excluded. The provided glob pattern has to match the entire package name.
2. `py.typed` files are not included by default.
3. `PKG-INFO` file in sdist is missing `Requires-Dist` fields - although this is not entirely compliant with the core metadata specification, it will work without problems. Setuptools-based sdists use a `*.egg-info/requires.txt` file to specify dependencies instead of `PKG-INFO`. The current version of `pip` is aware of that.
4. Output/traceback is too big/verbose: `setuptools` will print log messages to both stdout and stderr depending on the level configuration (`DEBUG` or `>= WARNING`). You might see all of them if you don’t redirect the stderr output.
5. `setuptools` might require cleaning the project (e.g. `rm dist build *.egg-info`) before new settings take place.

### Limitations in other tools (not related to this change)

1. `ini2toml` will not merge an existing `pyproject.toml` into the generated one
2. The implementation in this change will automatically set the [`Home-page` core meta data](https://packaging.python.org/en/latest/specifications/core-metadata/#home-page) based on the value of `project.urls`. PyPI might show duplicated links unless you use exactly `Homepage` in `project.urls` (no dashes, capital first letter):

```toml
[project.url]
Homepage = "http://..."

```

---

<div class="post-metadata">

**Author:** ![jwodder](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jwodder/32/236_2.png) [@jwodder](https://discuss.python.org/u/jwodder)\
**Post date:** [February 20, 2022, 8:44pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/2 "2022-02-20T20:44:17Z")

</div>

I just tried this out on [GitHub - jwodder/linesep: Handling lines with arbitrary separators](https://github.com/jwodder/linesep), which is my go-to project for experimenting with packaging stuff. Step 1 worked fine. Step 2 built fine, but I noticed the following:

- `ini2toml` dropped the `"wheel ~= 0.32"` entry from `build-system.requires` in addition to nullifying the change from step 1.
- The output from `ini2toml` lacks a terminating newline.
- Given how small the `project.readme` and `project.license` tables are, I’d prefer to see them rendered as inline tables.
- The `url` field in `setup.cfg` was converted to a project-url named “Homepage”, and this was automatically used in the built metadata as both a project-url and the Home-page field. That seems like an odd way to have users specify the field.

As for step 3, while I was able to get away with commenting out `tool.setuptools.package-dir` and `tool.setuptools.packages.find.namespaces`, commenting out any more of the suggested fields failed:

- With `tool.setuptools.packages.find.where = ["src"]` commented out (and with the `[tool.setuptools.packages.find]` header kept), the build failed with “error: package directory ‘src/test’ does not exist”. If I also comment out `[tool.setuptools.packages.find]`, then the build succeeds.
- With `tool.setuptools.package-dir = {"" = "src"}` commented out, the build failed with “ModuleNotFoundError: linesep”, apparently while trying to resolve the `attr:` spec for the version field.

Question: Are there plans to also merge `MANIFEST.in` into `pyproject.toml`? It’s needed for more than just package data; e.g., I want to include my docs, CHANGELOG, and `tox.ini` in sdists.

---

<div class="post-metadata">

**Author:** ![jwodder](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jwodder/32/236_2.png) [@jwodder](https://discuss.python.org/u/jwodder)\
**Post date:** [February 20, 2022, 8:59pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/3 "2022-02-20T20:59:30Z")

</div>

I also happen to have written [my own setuptools plugin](https://github.com/jwodder/versioningit) that’s like setuptools-scm but more flexible. When I tried these steps out on a project that uses it, although the `version` field was correctly marked dynamic and left out of the `[tool.setuptools.dynamic]` field, when I tried building after step 2, my plugin was completely ignored! Are setuptools.finalize\_distribution\_options entry points no longer honored?

---

<div class="post-metadata">

**Author:** ![hukkinj1](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hukkinj1/32/4394_2.png) [@hukkinj1](https://discuss.python.org/u/hukkinj1)\
**Post date:** [February 20, 2022, 9:25pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/4 "2022-02-20T21:25:53Z")

</div>

Thanks @abravalheri for working on this!

I tried this out on [mdformat](https://github.com/executablebooks/mdformat/pull/308).

Here’s my notes:

- I needed to add a `MANIFEST.in` file to include `py.typed`. Maybe this is a separate discussion, but it might be convenient to include this by default?
  - After adding `MANIFEST.in` I did have `py.typed` in the source distribution, but not the wheel. AFAIK both flit and poetry add this in a wheel, and mypy needs it to be there.

- dependencies were not added to the source distribution’s `PKG-INFO`. I.e. `Requires-Dist` fields were missing.
- `Description-Content-Type` in `PKG-INFO` was set to reST even though the file read is `README.md` (a Markdown file, not reST)

Other than that all seems good to me!

---

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 20, 2022, 9:43pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/5 "2022-02-20T21:43:17Z")

</div>

Thank you very much for the help and the feedback @jwodder.

Currently `ini2toml` have some limitations, e.g. it does not support merging documents 😅, so the automatic conversion is only “informational” for the time being (I am afraid it still requires manual merging the existing `pyproject.toml` file). Hopefully that will change in the future.

> [@jwodder](#):
>
> The `url` field in `setup.cfg` was converted to a project-url named “Homepage”, and this was automatically used in the built metadata as both a project-url and the Home-page field. That seems like an odd way to have users specify the field.

Yeap, this behaviour is a bit quirk. I don’t recall PEP 621 having an equivalent for the `Home-page` core metadata, which make the things worse. I thought that leaving it in both places would be the less problematic approach. Do you think it should be different?

Regarding step 3, my understanding is that I need to clarify more the docs, or raise a warning when no fields are given for `find`.

What is happening in your example is a combination of 2 effects:

- The presence of `[tool.setuptools.packages.find]` will cause setuptools to search for packages when the configuration file is processed.
- For backward compatibility, the auto-discovery will just quick in afterwards, if the user has not specified both `packages` and `py_modules`. So in your example, the auto-discovery will never be activated.

> [@jwodder](#):
>
> Question: Are there plans to also merge `MANIFEST.in` into `pyproject.toml` ? It’s needed for more than just package data; e.g., I want to include my docs, CHANGELOG, and `tox.ini` in sdists.

For the time being, I am not considering that, but this can be proposed in the issue tracker. I would like to see the opinions of the other setuptools maintainers before diving in 😄

> [@jwodder](#):
>
> Are setuptools.finalize\_distribution\_options entry points no longer honored?

I have to double check that. I have not explicitly removed any entry-point and I imagine that the callback is still there. Maybe this problem is related to the auto-discovery just happening after the plugin was already processed? (I will have a look on that, thank you very much for the pointer!)

---

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 20, 2022, 9:49pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/6 "2022-02-20T21:49:35Z")

</div>

Thank you very much @hukkinj1 for the help. I will have a look on the points you shared this week, there is probably something going wrong there, specially with the dependencies in the `PKG-INFO` and the automatic `Description-Content-Type`.

Regarding the `py.typed`, I also think that is a very worthy feature request. I will investigate more on that in a follow up.

---

<div class="post-metadata">

**Author:** ![jwodder](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jwodder/32/236_2.png) [@jwodder](https://discuss.python.org/u/jwodder)\
**Post date:** [February 20, 2022, 9:51pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/7 "2022-02-20T21:51:58Z")

</div>

> I thought that leaving it in both places would be the less problematic approach. Do you think it should be different?

If I were designing `pyproject.toml` support for setuptools, I’d just have `setup.cfg`’s `url` field converted to a `tool.setuptools.url` (or possibly `tool.setuptools.home-page`) field. If I wanted a Project URL named “Homepage”, I’d set it myself.

> What is happening in your example is a combination of 2 effects: …

While that explains why I get different behavior depending on whether the `[tool.setuptools.packages.find]` header is commented out, the "error: package directory ‘src/test’ does not exist” behavior seems like a bug to me (Why is it expecting a package directory named “test”? Is it because the default config excludes that package? If it excludes it, why it is a problem if it’s missing?), as does the fact that `tool.setuptools.package-dir` seems to be required to use `attr:` version specs when you say it should be automatically determined.

---

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 20, 2022, 9:53pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/8 "2022-02-20T21:53:42Z")

</div>

> [@jwodder](#):
>
> While that explains why I get different behavior depending on whether the `[tool.setuptools.packages.find]` header is commented out, the "error: package directory ‘src/test’ does not exist” behavior seems like a bug to me (Why is it expecting a package directory named “test”? Is it because the default config excludes that package? If it excludes it, why it is a problem if it’s missing?), as does the fact that `tool.setuptools.package-dir` seems to be required to use `attr:` version specs when you say it should be automatically determined.

Thanks @jwodder, I plan to investigate more this issue later this week!

---

<div class="post-metadata">

**Author:** ![layday](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/layday/32/2771_2.png) [@layday](https://discuss.python.org/u/layday)\
**Post date:** [February 20, 2022, 11:03pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/9 "2022-02-20T23:03:51Z")

</div>

> [@jwodder](#):
>
> If I were designing `pyproject.toml` support for setuptools, I’d just have `setup.cfg` 's `url` field converted to a `tool.setuptools.url` (or possibly `tool.setuptools.home-page` ) field. If I wanted a Project URL named “Homepage”, I’d set it myself.

I think deviating from PEP 621 for project metadata would be confusing. Specifically, see [PEP 621 – Storing project metadata in pyproject.toml | peps.python.org](https://www.python.org/dev/peps/pep-0621/#have-a-separate-url-home-page-field).

---

<div class="post-metadata">

**Author:** ![jwodder](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jwodder/32/236_2.png) [@jwodder](https://discuss.python.org/u/jwodder)\
**Post date:** [February 20, 2022, 11:15pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/10 "2022-02-20T23:15:44Z")

</div>

But PEP 621 doesn’t define a way to set the Home-page metadata field. You can’t deviate from what isn’t there.

---

<div class="post-metadata">

**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\
**Post date:** [February 20, 2022, 11:32pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/11 "2022-02-20T23:32:22Z")

</div>

It does.

```nohighlight
[project.urls]
homepage = "example.com"

```

---

<div class="post-metadata">

**Author:** ![jwodder](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jwodder/32/236_2.png) [@jwodder](https://discuss.python.org/u/jwodder)\
**Post date:** [February 20, 2022, 11:44pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/12 "2022-02-20T23:44:16Z")

</div>

That sets a [Project-URL](https://packaging.python.org/en/latest/specifications/core-metadata/#project-url-multiple-use) metadata field, not the [Home-page](https://packaging.python.org/en/latest/specifications/core-metadata/#home-page) field.

---

<div class="post-metadata">

**Author:** ![FFY00](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ffy00/32/4007_2.png) [@FFY00](https://discuss.python.org/u/FFY00)\
**Post date:** [February 21, 2022, 12:00am UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/13 "2022-02-21T00:00:30Z")

</div>

The homepage field can be taken from there. PEP 621 does not specify it, backends can implement however they like. I think the best option would be to use `projects.urls.homepage`.

---

<div class="post-metadata">

**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\
**Post date:** [February 21, 2022, 6:34am UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/14 "2022-02-21T06:34:30Z")

</div>

The Home-Page metadata key is treated roughly equivalently to a Homepage project URL on PyPI. There are no other known usecases of that key.

One of the “goals” of PEP 621 was to consolidate some of the “here’s two ways to achieve the same end goal” as well as separate the metadata layer names from the overall package. So, as folks are saying here: putting it in project.urls out of the box is reasonable. I think it’s fine to add a tool.setuptools.homepage-url — that isn’t “out of spec”, it’s just that the difference between doing it that way and the way it’s done currently is too-subtle and having a smaller surface area would be helpful IMO (PS: don’t make the mistake of mirroring setuptools’ bad defaults and option names in pyproject.toml please!).

This means that we’ve omitted some keys that felt redundant, or didn’t really see much value to.

---

<div class="post-metadata">

**Author:** ![fungi](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/fungi/32/5963_2.png) [@fungi](https://discuss.python.org/u/fungi)\
**Post date:** [February 21, 2022, 1:33pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/15 "2022-02-21T13:33:25Z")

</div>

[…]

Just to clarify, there are no other use cases for the Home-Page  
metadata key known to you? Can you be more specific about what you  
mean by “known” in this instance? How was that statistic arrived at?

Similarly, will the License metadata key be discarded in favor of  
the Trove classifiers for License? PyPI treats them roughly  
equivalently, and I know of no other use cases for it.

---

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 21, 2022, 2:21pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/16 "2022-02-21T14:21:44Z")

</div>

Currently what is implemented is that `projects.urls.homepage` (and variants like `home-page`, `Home-page`, etc…) is being used to backfill the core metadata field `Home-page`. A similar thing is also done for `Download-URL`.

This looked to me the “safest” approach, since I conjectured that other tools could have been relying on these fields.

It is nice to known that PyPI will do the right thing if `Home-page` is not present, but an equivalent entry is found in `Project-URL`.

---

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 21, 2022, 2:53pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/17 "2022-02-21T14:53:28Z")

</div>

> [@hukkinj1](#):
>
> dependencies were not added to the source distribution’s `PKG-INFO` . I.e. `Requires-Dist` fields were missing.

Hi @hukkinj1, I was just investigating this issue first since it seems very problematic.

To understand the state of affairs I decided to inspect `build` as an example (it does currently depends on setuptools). As we can see by running the following commands, it does have a series of dependencies:

```bash
$ wget https://files.pythonhosted.org/packages/py3/b/build/build-0.7.0-py3-none-any.whl
$ unzip -c build-0.7.0-py3-none-any.whl build-0.7.0.dist-info/METADATA | grep -i requires
Requires-Python: >=3.6
Requires-Dist: packaging (>=19.0)
Requires-Dist: pep517 (>=0.9.1)
...

```

However, this dependencies are currently not being added to `PKG-INFO`:

```bash
$ wget https://files.pythonhosted.org/packages/source/b/build/build-0.7.0.tar.gz
$ tar xOf build-0.7.0.tar.gz build-0.7.0/src/build.egg-info/PKG-INFO | grep -i requires
Requires-Python: >=3.6

```

Instead, they reside in a `requires.txt` inside the `egg-info` folder:

```bash
tar xOf build-0.7.0.tar.gz build-0.7.0/src/build.egg-info/requires.txt :(
packaging>=19.0
pep517>=0.9.1
tomli>=1.0.0
...

```

So this behaviour is just regular setuptools behaviour, not specific to the “project-metadata in pyproject.toml” feature implementation. I will file an issue in the issue tracker (or at least check if one already does not exist).

* * *

Update, the issues already exist: [#1716](https://github.com/pypa/setuptools/issues/1716) and [1805](https://github.com/pypa/setuptools/issues/1805).

---

<div class="post-metadata">

**Author:** ![LewisGaul](https://avatars.discourse-cdn.com/v4/letter/l/bc79bd/32.png) [@LewisGaul](https://discuss.python.org/u/LewisGaul)\
**Post date:** [February 21, 2022, 2:55pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/18 "2022-02-21T14:55:51Z")

</div>

I’ve tried out getting my minesweeper project to work with your setuptools branch (see [here](https://github.com/LewisGaul/minegauler/compare/dev...packaging)).

I came across a few issues:

- `setuptools._vendor._validate_pyproject.fastjsonschema_exceptions.JsonSchemaValueException: data.urls.homepage must be url` - my URL field did not start with ‘https://’, but [the example in PEP 621](https://www.python.org/dev/peps/pep-0621/#example) suggested this should work
- `setuptools._vendor._validate_pyproject.fastjsonschema_exceptions.JsonSchemaValueException: data.minegauler-bot must be python-entrypoint-reference` - I was specifying `"minegauler.cli"` as an entrypoint, expecting it to do the equivalent of `python -m minegauler.cli`, but it seems I needed to use `"minegauler.cli. __main__ :main"`, is this expected?
- I hit an issue with optional dependencies that I haven’t diagnosed yet, I may report back later
- When building sdist I see “warning: check: missing meta-data: either (author and author\_email) or (maintainer and maintainer\_email) should be supplied” - this is despite the fact I have both authors and maintainers, e.g. `authors = [{name = "Lewis Gaul", email = "minegauler@gmail.com"}]`
- I was hoping `packages` and `package_data` would still be possible to specify in `setup.py` rather than figuring out the `tool.setuptools` section or adding a `setup.cfg`, but these seem to be ignored

Other questions/thoughts:

- I’m seeing “Install `trove-classifiers` to ensure validation.” - is this something that should be included in `build-system: requires`?
- One other thought: when hitting these backend errors a pretty big setuptools traceback is output, which doesn’t feel very user-friendly (I only needed the exception message).

Looking forward to this functionality getting released, thanks for your work on this!

---

<div class="post-metadata">

**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\
**Post date:** [February 21, 2022, 3:06pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/19 "2022-02-21T15:06:46Z")

</div>

Thank you very much for the feedback Lewis. Most of the points you specified are definitely corrections to be made. I am collecting all these issues in a backlog!

> [@LewisGaul](#):
>
> I’m seeing “Install `trove-classifiers` to ensure validation.” - is this something that should be included in `build-system: requires` ?

If you add `trove-classifiers` to your `build-system: requires` it should do the validation. Let me know if it does not work.

> [@LewisGaul](#):
>
> I was hoping `packages` and `package_data` would still be possible to specify in `setup.py` rather than figuring out the `tool.setuptools` section or adding a `setup.cfg` , but these seem to be ignored

I will have a look on minesweeper to understand what is happening. I was doing an experiment with [pybind11](https://github.com/pybind/pybind11/pull/3711), and it seemed to work at that point it time.

---

<div class="post-metadata">

**Author:** ![LewisGaul](https://avatars.discourse-cdn.com/v4/letter/l/bc79bd/32.png) [@LewisGaul](https://discuss.python.org/u/LewisGaul)\
**Post date:** [February 21, 2022, 3:27pm UTC](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821/20 "2022-02-21T15:27:08Z")

</div>

> [@abravalheri](#):
>
> I will have a look on minesweeper to understand what is happening. I was doing an experiment with [pybind11](https://github.com/pybind/pybind11/pull/3711), and it seemed to work at that point it time.

Ah in which case it could well be something to do with me switching to namespace packages at the same time or something - I’m happy to diagnose a bit further and let you know what I find 🙂

[Next page](https://discuss.python.org/t/help-testing-experimental-features-in-setuptools/13821.md?page=2)