Pyproject toml

[kyleaoman]

Move from setup.py to pyproject.toml. Notes:

• The version is hardcoded in the pyproject.toml file instead of read from the version file. Some googling suggests that there is not way around this that doesn't make more of a mess than it's worth.
• I didn't include a long description, but pyproject.toml lets you point to the readme file, so I think that covers the same role.

[JBorrow]

As discussed before, I think simply adding the build environment pyproject.toml should suffice here :)

[kyleaoman]

@JBorrow I put back the setup.py file.

[MatthieuSchaller]

@JBorrow any last thoughts?

[JBorrow]

Can pyproject.toml not be much reduced now we are still using the old build system? I think all you need to do is specify that it uses setuptools.

[MatthieuSchaller]

@kyleaoman any thoughts on Josh's last point?

[kyleaoman]

(long delay because...)

I guess I'm unsure whether to follow Josh's whims or the recommendations of setuptools and python. The general recommendation seems to be to use first pyproject.toml (including with setuptools) and then include setup.py if it is needed. For instance (source, which is the up to date guidance following PEP 621):

Also, the setuptools build backend supports both the [project] table, and the older format in setup.cfg or setup.py. For new projects, it is recommended to use the [project] table, and keep setup.py only if some programmatic configuration is needed (such as building C extensions), but the setup.cfg and setup.py formats are still valid. See Is setup.py deprecated?.

And from setuptools:

Starting with PEP 621, the Python community selected pyproject.toml as a standard way of specifying project metadata. Setuptools has adopted this standard and will use the information contained in this file as an input in the build process.

If compatibility with legacy builds or versions of tools that don’t support certain packaging standards (e.g. PEP 517 or PEP 660), a simple setup.py script can be added to your project [1] (while keeping the configuration in pyproject.toml):

from setuptools import setup
setup()

My suggestion would therefore be to revert the last commit on this branch (i.e. delete setup.py again) and merge. But @JBorrow if you have a different preference that's of course fine, however in that case I don't know how you want to implement it so I'll leave it to you.

[JBorrow]

Ok, I am happy with this now.

[JBorrow]

I think we should merge this and then re-visit changing from setup.py to pyproject.toml from there. Kyle, we should also get you write access to the repo.

[MatthieuSchaller]

Kyle is already a maintainer.

Note that this whole project should be destined for death pretty soon. We should access the SOAP catalogs directly via swiftsimio without the need of an intermediate tool.

[JBorrow]

Unless this has been changed, the autoplotter still lives in velociraptor. Kyle is a maintainer because I just made him a maintainer :).

[MatthieuSchaller]

Indeed, but that should really disappear too.

[JBorrow]

As in it will be re-written, or moved?

[MatthieuSchaller]

neither at this stage.

[kyleaoman]

When this is killed off I'd appreciate a bit of warning so that I can update swiftgalaxy, which relies heavily on this for docs and tests. Would like to move that to SOAP first, but that implies having a functional i/o package for SOAP.

[kyleaoman]

Should I deal with the suggested changes and merge this in, then? Probably not worth the bother woth pyproject.toml if this is getting mothballed anyway.

[JBorrow]

I think that makes the most sense, thanks Kyle.

[kyleaoman]

@JBorrow I think that I've done all that I can on my end, merging is blocked until there's an approving review (and I can't approve as the PR author).