Skip to content

upgrade poetry2.0 & apply pep621 #545

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

Merged
merged 7 commits into from
Feb 27, 2025

Conversation

phi-friday
Copy link
Contributor

@phi-friday phi-friday commented Feb 11, 2025

What's different in poetry2.0: Announcing Poetry 2.0.0

Since poetry2.0 now supports pep621, I was able to modify pyproject.toml to conform to the standard spec.
(I kept the modifications to a minimum).
(Since install-poetry doesn't support poetry2.0, I've changed how to install poetry from github action. snok/install-poetry#164)

However, it does not yet support pep735 (dependency groups), so the proprietary specification tool.poetry.group is retained.
However, this too will be fixed in the future. python-poetry/poetry#9751

If we use poetry in the future, it seems like a good idea to upgrade poetry to 2.0 if possible, as all improvements will only be for 2.0 or later.

Copy link
Member

@till-m till-m left a comment

Choose a reason for hiding this comment

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

LGTM, generally speaking. Will merge soon.

It seems a bit weird to install uv, to then install poetry later. Using just uv would be nice in the future, but I'm a bit worried about breaking the publishing workflow. Something to keep in mind for the future.

@phi-friday
Copy link
Contributor Author

LGTM, generally speaking. Will merge soon.

It seems a bit weird to install uv, to then install poetry later. Using just uv would be nice in the future, but I'm a bit worried about breaking the publishing workflow. Something to keep in mind for the future.

I prefer uv to poetry, so I agree with the later change to uv.
(The late support for PEP621 was a big part of what made me move to uv).

But I also agree with the concerns you mentioned.
uv is a good tool, but it will cause problems for other workflows that are already used to poetry and are already aligned with poetry.
Also, using uv as a project package manager will force existing contributors to re-familiarize themselves with uv.
So it's kind of weird, but I've only made some adaptations to uv in github actions.

PS1.
Applying uv is not necessarily just for installing poetry.
I use uv to generate requirements with numpy conditions applied.
This was hard to do cleanly with poetry alone.

PS2.
The reason I changed the way I install poetry is fixed.
snok/install-poetry#164 (comment)
Since python>=3.9 doesn't cause the problem, I think we can keep using install-poetry as is.
(BayesianOptimization requires python>=3.9).
I'll fix it soon.

@till-m
Copy link
Member

till-m commented Feb 27, 2025

I'll fix it soon.

In that case I will wait with merging this :)

@phi-friday
Copy link
Contributor Author

I'll fix it soon.

In that case I will wait with merging this :)

i fixed it

@till-m till-m merged commit 232f9d9 into bayesian-optimization:master Feb 27, 2025
12 checks passed
@till-m
Copy link
Member

till-m commented Feb 27, 2025

Thanks for the contribution :)

adrianmolzon pushed a commit to adrianmolzon/BayesianOptimization that referenced this pull request Mar 9, 2025
* chore: upgrade poetry2.0 & apply pep621

* fix: replace poetry action(not support 2.0)

* fix: exclude one matrix

* chore: split numpy deps

* fix: numpy constraints

* fix: install root

* chore: use install-poetry
till-m added a commit that referenced this pull request Mar 17, 2025
* Add functionality to save and load state of the BayesianOptimization

* Update basic-tour with new save and load functionality

* move load stateful path to optional argument in class instantiation

* add test for string params, update tests with new load functionality

* updated basic tour with updated paths

* add the random state to the set of things to list of saved items

* move state loading to separate function, add functionality for saving acquisition function state

* use new loading schema

* update tests, add integration tests for saving and loading acquisition functions

* undo abstractmethod implementation for get and set state saving functionality

* reorganize state saving and loading for consistency

* move integration tests into acquisition

* remove unndecessary test, add tests for domain reduction and custom parameters

* make test more comprehensive

* add test logs

* sync execution counts from basic tour

* linting, whitespace removal, import structuring

* ruff fix for string literal in error message

* fix ruff complaints

* make all side param comparisons almost equal to account for slight numpy differences

* reformat array comparison check

* upgrade poetry2.0 & apply pep621 (#545)

* chore: upgrade poetry2.0 & apply pep621

* fix: replace poetry action(not support 2.0)

* fix: exclude one matrix

* chore: split numpy deps

* fix: numpy constraints

* fix: install root

* chore: use install-poetry

* Fix coverage report (#552)

* remove unnecessary files, have acquisition baseclass functions raise errors

* remove duplicate acquisition functions random state

* ruff format

* add  type hints for base acquisition get/set functions

* remove noreturn

* remove former saving functionality from notebooks

* increase legibility of custom acquisition example

* explicitly stating the optionality of the saving and loading in custom acq functions

---------

Co-authored-by: phi-friday <[email protected]>
Co-authored-by: till-m <[email protected]>
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.

2 participants