feat: setup a pyproject.toml #27859
feat: setup a pyproject.toml #27859
Conversation
Decomposing a previous PR into smaller parts. Using a pyproject.toml will enable us to use `supersetbot` to replace dependabot in managing/bumping our python libraries. The fact that pyproject is parsable enables more automation down the line
github-actions
bot
added
the
github_actions
github-actions
bot
removed
the
github_actions
| sqloxide | ||
| statsd | ||
| tox | ||
| -e .[development,bigquery,cors,druid,gevent,gsheets,hive,mysql,playwright,postgres,presto,prophet,trino,thumbnails] |
There was a problem hiding this comment.
note that I added development here, which is referencing a group that contains the libs referenced in the file bellow, now in pyproject.toml
|
I don't think there's anything controversial here, just moving dep management to a new, parsable file that is becoming the standard. Mergin' |
| # apache-superset | ||
| # pyhive | ||
| # thrift-sasl | ||
| thrift-sasl==0.4.3 |
There was a problem hiding this comment.
@mistercrunch the removal of thrift-sasl (which should be included via pyhive[hive_pure_sasl]) is breaking CI, i.e., for test-postgres-hive, I'm seeing,
> import thrift_sasl
E ModuleNotFoundError: No module named 'thrift_sasl'
i.e., something seems amiss with the frozen requirements when using pyproject.toml.
There was a problem hiding this comment.
I think that was bad merge conflict resolution, but interestingly this PR brought it back - guessing through a pip-compile-multi --no-upgrade run -> https://github.com/apache/superset/pull/27631/files#diff-f449835486933e5cab23a8567940e46d53edd89923cf1a3a4fb83005b069a93fR260
Now I did another run here -> #27861
|
@mistercrunch is the intent to:
|
|
My main intent was to be able to parse the dependencies to support |
Following up on #27859, where I introduced a new file `pyproject.toml` to set up the python project metadata, here I'd like to consolidate and modernize further by pushing as much as possible into pyproject.toml, except where things need to be dynamic, for which we'll keep using setup.py: - get rid of setup.cfg, everything there should be able to move to pyproject.toml - remove duplicate keys from setup.py and pyproject.toml - minimize/simplify setup.py
Following up on #27859, where I introduced a new file `pyproject.toml` to set up the python project metadata, here I'd like to consolidate and modernize further by pushing as much as possible into pyproject.toml, except where things need to be dynamic, for which we'll keep using setup.py: - get rid of setup.cfg, everything there should be able to move to pyproject.toml - remove duplicate keys from setup.py and pyproject.toml - minimize/simplify setup.py
Following up on #27859, where I introduced a new file `pyproject.toml` to set up the python project metadata, here I'd like to consolidate and modernize further by pushing as much as possible into pyproject.toml, except where things need to be dynamic, for which we'll keep using setup.py: - get rid of setup.cfg, everything there should be able to move to pyproject.toml - remove duplicate keys from setup.py and pyproject.toml - minimize/simplify setup.py
Decomposing a previous PR into smaller parts.
Using a pyproject.toml will enable us to use
supersetbotto replacedependabot in managing/bumping our python libraries. The fact that
pyproject is parsable enables more automation down the line