Migrated the metadata into pyproject.toml

[KOLANICH]

Description
Setuptools now supports PEP 621 ::tada::

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[defunctzombie]

Whats the benefit of this over the existing file? Will this break compatibility with clients that don't yet support this new PEP?

[jtbandes]

Thanks for the suggestion. But this seems to break pipenv install:

pipenv.patched.notpip._internal.exceptions.InstallationError: File "setup.py" or "setup.cfg" not found. Directory cannot be installed in editable mode: /home/runner/work/mcap/mcap/python
(A "pyproject.toml" file was found, but editable mode currently requires a setuptools-based build.)

Because of this line:

mcap/python/Pipfile

Line 9 in 743b1f8

mcap = { editable = true, path = "." }

Maybe this line isn't strictly required. But I think it helps with development because it prevents cached .pyc files from being used...but I could be wrong about this.

[KOLANICH]

I don't use pipenv (and consider usage of venvs as recommended by some people and as put into base of such tools as pipenv and poetry as a cargo cult), but I wonder if you have tried to upgrade pipenv and comment out the lines with the checks. Because for just pip and setuptools of the latest versions editable installs work very fine.

[KOLANICH]

Will this break compatibility with clients that don't yet support this new PEP?

It will. But ones installing from pypi install wheels. PEP 621 is used only on the stage of building wheels. pyproject.toml doesn't go into wheels.

Whats the benefit of this over the existing file?

1. setup.cfg is planned to be deprecated and removed soon, noone wants to maintain support of this config where each field has own format and syntax.
2. PEP 621 is the standard. If a user wishes to use flit_core or poetry_core as build backends, the changes to the config would be minimal, and can be fully automated.
3. Again, it is the standard that is easier to support by external tools.

[jtbandes]

Based on this issue I wonder if simply upgrading pip would be enough to make this work. Could you try upgrading the pip version, or enabling allow edits from maintainers so that we can work on it?

[KOLANICH]

pipenv has an own vendored patched obsolete version of pip called nonpip. Its repo also contains some scripts to update the vendored dependencies. But they don't work on my machine.

[jtbandes]

It looks like there is a pipenv issue tracking this error (ability to install pyproject.toml-only projects as editable): pypa/pipenv#4375

It doesn't seem like there is a strong reason to switch CI tooling just for the purpose of pushing this change forward. I don't see any harm in waiting for pipenv to support it. I don't think we need to be installing pre-release versions of python tooling in this repo's CI.

If a user wishes to use flit_core or poetry_core as build backends, the changes to the config would be minimal, and can be fully automated.

By "a user", do you mean a developer working in this repo, or an end user of the package? I believe this change will only affect developers of this repo and not end users. Is that right?

setup.cfg is planned to be deprecated and removed soon

Do you have a link to more information about this deprecation? I wasn't able to find anything. https://stackoverflow.com/questions/44878600/is-setup-cfg-deprecated

[jtbandes]

I filed another issue to track support for pyproject.toml-only packages in editable mode: pypa/pipenv#5055

[KOLANICH]

Do you have a link to more information about this deprecation? I wasn't able to find anything. https://stackoverflow.com/questions/44878600/is-setup-cfg-deprecated

pypa/setuptools#3214

I don't see any harm in waiting for pipenv to support it.

Sure.

By "a user", do you mean a developer working in this repo, or an end user of the package? I believe this change will only affect developers of this repo and not end users. Is that right?

There are users like me who install packages from git if it is affordable (i.e. doesn't involve multi-hour compilation). Because I love being on bleeding edge and using the freshest features instead of reinventing wheels.

[jtbandes]

It seems a new pipenv version was released which upgrades the vendored version of pip. However now the install is failing with a different error.

[KOLANICH]

It seems pipenv passes --no-use-pep517 flag to own pip. I havent' succeed to remove it.

[defunctzombie]

Thanks for proposing this change and explaining some more about it. However, I don't see what benefit this brings over our current approach for the python package so I'm gonna close this out. If you want us to re-visit this we'd need to understand what this does better than what we have and what the downsides are of switching to this over what we have.

[KOLANICH]

what benefit this brings

No benefit for the project. If project developers don't need anything but pipenv, then there is no benefit for them personally.