Skip to content

Conversation

@deathaxe
Copy link
Member

This PR...

  1. refactors folder structure as if sublime_lib was an ordinary python library.
  2. adds pyproject.toml to specify all relevant metadata
  3. retires flake8 and pycodestyle in favour of black.
  4. adds relevant scripts and actions to deploy the library as WHEEL via Github releases.

Version is bumbed to 1.6.0, but this PR doesn't change any library functionality at all.

@Thom1729
Copy link
Member

I'm flying to Munich today and probably won't have a chance to look at this for at least a week, but it sounds good in principle and I have no objections if @FichteFoll wants to review it in the meantime.

@FichteFoll
Copy link
Member

FichteFoll commented Nov 23, 2025

I'll take a look at it next weekend, probably.

Edit: although I am in general in favor of ruff over black formatting.

@deathaxe
Copy link
Member Author

Have no strong favourite. Black just was an easy change. Feel free to change the formatter/checker.

@FichteFoll
Copy link
Member

I took a jab at it via #179, PTAL.

FichteFoll and others added 5 commits December 23, 2025 18:48
Use single worker instance to perform both flake8 and pycodestyle checks.
No need to spin up 2 separate VMs for those related tasks.
Stupid restriction, but despite a project supporting e.g. python 3.3,
and only some secondary tools like sphinx needing more recent versions to run,
uv fails to install it due to specified `required-python` value.

Actually an argument to ditch uv, especially as all the CI is damn naive simple,
and uv seems over the top for it, but well. It's the current hype.
@deathaxe deathaxe force-pushed the feat/release-as-wheel branch from ad1c037 to d7d3926 Compare December 23, 2025 18:03
@deathaxe
Copy link
Member Author

deathaxe commented Dec 23, 2025

Updated this PR, re-using most CI and workflow stuff from #179, but without changing any library code.

I actually don't feel very comfortable with dynamically creating an additional _version.py which is present only in created wheel file. I'd prefer version information to always be present, even in original sources, but I see the benefits of creating a wheel and attach it to GH release after adding and pushing a version tag.

I'd suggest to build a v1.6.0 release from this one and than upgrade library code from #179 to require python 3.8+ and release it as v1.7.0 or even v2.0.0 to denote the breaking change.

deferred is the default in current releases
This commit enables python version specific releases without dedicated
releases or tag-prefixes by creating ...

  sublime_lib-m.m.p-py33-none-any.whl
  sublime_lib-m.m.p-py38-none-any.whl

which can be targetted by `"asset": "sublime_lib-*-${py_version}-none-any.whl"`
in repositories' release specification.
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