Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modernise dataset template #95

Open
xrotwang opened this issue Jan 21, 2025 · 4 comments
Open

Modernise dataset template #95

xrotwang opened this issue Jan 21, 2025 · 4 comments

Comments

@xrotwang
Copy link
Contributor

In the dataset templates we should use a pyproject.toml-based approach (rather than setup.py). Something along the lines of this seems to work:

[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

[project]
name = "cldfbench_languageatlasofthepacificarea"
version = "2.0"
dependencies = [
    'cldfbench',
    'pyglottolog',
    'fiona',
    'shapely',
    'cldfgeojson',
    'mako',
    'matplotlib',
    'tqdm',
]

[tool.setuptools]
packages = ["lib", "laotpa_commands"]
py-modules = ["cldfbench_languageatlasofthepacificarea"] # dash, not underscore

[project.optional-dependencies]
test = ['pytest-cldf']

[project.entry-points."cldfbench.dataset"]
languageatlasofthepacificarea = 'cldfbench_languageatlasofthepacificarea:Dataset'

[project.entry-points.'cldfbench.commands']
laotpa = 'laotpa_commands'
@johenglisch
Copy link
Contributor

I played around with the idea before but ultimately gave up. The problem is that this breaks downstream packages that ‘inherit’ from the dataset template and ‘override’ some of the files (including setup.py_tmpl), e.g.:

https://github.com/lexibank/pylexibank/tree/master/src/pylexibank/dataset_templates/lexibank_simple

@xrotwang
Copy link
Contributor Author

Hm. Alternatively, we could add a "modenize" command of sorts, that takes an existing setup.py and turns it into the equivalent pyproject.toml. This might be the better option anyway, because it would also address the many existing dataset repositories. But then, we might better wait until setup.py actually breaks and switch to the best practice recommended then.

@johenglisch
Copy link
Contributor

a "modenize" command of sorts, that takes an existing setup.py and turns it into the equivalent pyproject.toml

Hm, that would involve parsing a python file – I don't know if we want to go down that rabbit hole if we don't have to.

But then, we might better wait until setup.py actually breaks and switch to the best practice recommended then.

Yeah, I think that would be for the best. From what I see pyproject.toml doesn't actually do anything new that we need (apart from supporting build systems other than setuptools, which we're unlikely to switch to). Plus, when I played around with the pyproject.toml I found that there are some tools (flake8 for instance) which only support setup.cfg, so I ended up with all three file formats in the same project (py, cfg, and toml).

So, I don't really see any benefits in ‘modernising’ here. Also, who knows how many more config files the ecosystem will have XKCD 927'd into existence by the time setup.py actually stops working… (maybe a json file, and a yaml file for good measure) (<_<)"

@LinguList
Copy link
Contributor

I lack the proficiency and experience of @johenglisch and @xrotwang here, but I played around with pyproject.toml (they have a little package to turn cfg files to toml, and I managed to run the pip installation for edictor project without greater problems, but I did not yet look deeper into flake and the like. Thus, if it means we must keep the cfg-files anyway, plus the empty setup.py, we could as well wait (but we'd need to switch from setup.py with code to using cfg files).

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

No branches or pull requests

3 participants