Skip to content

Consolidate setup.py metadata, remove old setup.py files#1376

Merged
jorisvandenbossche merged 7 commits intoshapely:mainfrom
jorisvandenbossche:consolidate-setup
Jun 19, 2022
Merged

Consolidate setup.py metadata, remove old setup.py files#1376
jorisvandenbossche merged 7 commits intoshapely:mainfrom
jorisvandenbossche:consolidate-setup

Conversation

@jorisvandenbossche
Copy link
Copy Markdown
Member

After merging pygeos into shapely, the setup() function in setup.py for now only had a minimal content to have the installation working. With this PR, I am also trying to consolidate the additional metadata passed to setup().
For the most part this combines the values of the previous setup.py files from shapely and pygeos (those were kept as setup_shapely.py and setup_pygeos.py for now, which I deleted in this PR), except for a few open questions (see the inline comments as well):

  • What short "description" do we want to use?
  • Which author/maintainer (and email) to list?

cc @sgillies @caspervdw

setup.py Outdated
Comment on lines +217 to +219
description="Manipulation and analysis of geometric objects",
# description="GEOS wrapped in numpy ufuncs",
# description="Geometric objects, predicates, and operations",
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The two descriptions commented out are from pygeos and shapely, respectively. The one that I used now (not commented out) is the one from the github repo's tagline here. Any preferences? (or alternatives?)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I like the one you selected 👍

setup.py Outdated
Comment on lines +224 to +225
author="Sean Gillies, Casper van der Wel, and the Shapely contributors",
author_email="sean.gillies@gmail.com, caspervdw@gmail.com",
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

It's not very clear what the requirements are around "author" (and you also have "maintainer" as alternative/additional field), for example, should it be a single person, or can it be multiple as I did here?

Some other packages put the developer mailing list as "email", but that's not something we have.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I think it is best to sidestep this issue by not including this field at all. I strongly prefer people raising issues at github instead of emailing me.

Concerning the “author” field; I am a bit torn on this point. I like to have some credits for designing and building pygeos, but others have invested considerable amount of effort in the past years as well (like yourself @jorisvandenbossche). What warrants being listed as an “author”?

In practice this field gets set by the creator of the project. There is something sensible in this because it is mostly the one who thought up the idea of the project in the first place. Numpy for instance has Travis Oliphaunt as author but “NumPy maintainers” as maintainer. And maintainer supersedes author in the PKG_INFO (see docs https://setuptools.pypa.io/en/latest/references/keywords.html) Related to this is #1379

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

So then keeping "Sean Gillies" as author and add "Shapely contributors" as maintainer? That would be fine with me as well.
(numpy also has " et al." after the author name)

@coveralls
Copy link
Copy Markdown

coveralls commented May 1, 2022

Pull Request Test Coverage Report for Build 2488429169

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 84.361%

Totals Coverage Status
Change from base Build 2488011335: 0.0%
Covered Lines: 2147
Relevant Lines: 2545

💛 - Coveralls

@mwtoews
Copy link
Copy Markdown
Member

mwtoews commented May 15, 2022

Is there any apatite in moving static metadata to setup.cfg? This would reserve setup.py only for dynamic package building.

Further down the pipe is moving static metadata to pyproject.toml, however this is still regarded as "experimental".

@jorisvandenbossche
Copy link
Copy Markdown
Member Author

jorisvandenbossche commented May 18, 2022

Is there any apatite in moving static metadata

Yes, although I was maybe thinking we can also wait a bit longer and directly move to pyproject.toml? (although the move from setup.cfg to pyproject.toml might be trivial, didn't check that)

@mwtoews
Copy link
Copy Markdown
Member

mwtoews commented May 23, 2022

Transferring metadata from setup.cfg -> pyproject.toml is not really 1:1, as there is a bit of reorganisation (described in PEP 621). While it is experimental support from setuptools, modern PyPA tools like build and twine are pretty good at showing diagnostic messages if any of the metadata is out-of-line. So sure, I'd support transferring static metadata to pyproject.toml

setup.py Outdated
url="https://github.com/shapely/shapely",
keywords="geometry topology gis",
author="Sean Gillies",
author_email="sean.gillies@gmail.com",
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Comment from discussion: leave out email

@jorisvandenbossche
Copy link
Copy Markdown
Member Author

Going to merge this so we have a proper setup.py. We can do a move to pyproject.toml in a follow-up PR.

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.

4 participants