Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Comments

Move build metadata from setup.py to pyproject.toml.#592

Merged
bsteffensmeier merged 3 commits intoninia:dev_4.3from
bsteffensmeier:pyproject-toml
Jan 26, 2025
Merged

Move build metadata from setup.py to pyproject.toml.#592
bsteffensmeier merged 3 commits intoninia:dev_4.3from
bsteffensmeier:pyproject-toml

Conversation

@bsteffensmeier
Copy link
Member

This moves the build metadata into pyproject.toml. As far as I can tell there is no immediate benefit to this change but it aligns with current best practices for building a python project and I suspect it is inevitable we will need to use pyproject.toml at some point in the future so I would like to have a starting version to work with in the future.

With this change I am still able to build using either pip install --no-build-isolation . or setup.py install. I still get a deprecation warning when running setup.py directly.

Copy link
Member

@ndjensen ndjensen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How are you able to tell the install is using pyproject.toml instead of setup.py? Or does it use both?

Do you know if there is still a way to run individual build commands like clean, java, build_ext, test?

pyproject.toml Outdated
name = "jep"
description = "Jep embeds CPython in Java through JNI."
dynamic = ["version"]
#version = "4.3.0"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is version commented out?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I forgot to remove that when I got the dynamic version working. Leaving the version specifier in the setup() call in setup.py allows it to pick up the version in version.py so we don't have to remember to keep this version in sync. I will remove the commented out version.

@@ -0,0 +1,45 @@
[build-system]
requires = ["setuptools >= 61.0"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the version that first included distutils? How did you pick the version?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bsteffensmeier
Copy link
Member Author

How are you able to tell the install is using pyproject.toml instead of setup.py? Or does it use both?

It is always using both.

When you run a pip install then pip will read pyproject.toml and the build-system section instructs it to use setuptools and setuptools has logic which calls setup.py. Then when setuptools.setup() runs it reads pyproject.toml and fills in all the metadata that was previously in python.

If you just call setup.py without pip then it still loads metadata from pyproject.toml.

Do you know if there is still a way to run individual build commands like clean, java, build_ext, test?

I am able to use those by running setup.py directly. There is no change that I can see in how those work. setup.py still prints a deprecation warning saying you shouldn't call it but it still works.

pyproject.toml Outdated
name = "jep"
description = "Jep embeds CPython in Java through JNI."
dynamic = ["version"]
license = { "text" = "zlib/libpng"}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

license is an attribute that confused me and may need more work in the future. We have the option to specify a license file or license text but when I tried the file it embedded the full license into the setup.cfg which is included in the upload to pypi and I am not sure how that shows up on pypi so I reverted to the simple text here which makes the setup.cfg match what it did before.

It also seems that PEP-639 was just approved and applied to the pyproject.toml specification last month. According to the current documentation the license needs to be a valid SPDX identifier which this doesn't seem to be. But the versions of pip I was testing with don't support PEP-639 so I don't think we can actually update until we drop support for all older versions of Python.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think ours is the one listed as zlib. https://opensource.org/license/zlib

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think I should change this to zlib?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should be Zlib to match the SPDX identifier? The SPDX page doesn't mention libpng but the OSI page does, so I think it's the same thing.

@bsteffensmeier bsteffensmeier merged commit 8d496d1 into ninia:dev_4.3 Jan 26, 2025
1 check passed
@bsteffensmeier bsteffensmeier deleted the pyproject-toml branch July 4, 2025 18:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants