Ci/homogenize workflows with GC.OS repositories#702
Ci/homogenize workflows with GC.OS repositories#702tingiskhan wants to merge 12 commits intoPyPortfolio:mainfrom
Conversation
|
@fkiraly Would it make sense to have a dedicated devops repo associated with sktime where re-usable workflow components are stored? |
Yes, that sounds like an excellent idea. I think @tschm has set this up for their repos. However, I think it is not a priority currently when compared to getting ppfopt back on track. |
fkiraly
changed the title
fkiraly
added
the
maintenance
| uses: astral-sh/setup-uv@v7 | ||
| with: | ||
| enable-cache: true | ||
|
|
.github/workflows/test.yml
Outdated
| run: uv pip install ".[dev,all_extras]" --no-cache-dir | ||
| env: | ||
| UV_SYSTEM_PYTHON: 1 | ||
| run: uv sync --extra all_extras --extra dev --no-cache |
There was a problem hiding this comment.
I would go for uv pip install rather than uv sync. See long discussion on the topic in sktime.
| line-ending = "auto" | ||
| skip-magic-trailing-comma = false | ||
|
|
||
| [dependency-groups] |
There was a problem hiding this comment.
why move it here? I think we should just leave it in non-uv format
There was a problem hiding this comment.
This is actually the pip standard as of 25.1: https://packaging.python.org/en/latest/specifications/dependency-groups/
There was a problem hiding this comment.
The biggest benefit is that you can install just the dependencies inside that group, without having to install the full suite of packages - something I've longed for!
There was a problem hiding this comment.
indeed, you are right - introduced in 2025! I must have missed this.
Yes, `notebook-test´ should then also be here.
We should also think about how and whether to move this in the other GC.OS packages. sktime will move to 1.0 soon, that is an opportunity to move all the dev/testing related depsets to dependency-groups.
fkiraly
left a comment
fkiraly
left a comment
There was a problem hiding this comment.
Thanks!
Looks mostly good, but in some places it notably diverges from the "close to pip setup" to more uv based idioms. I think these may be problematic and shuld be reverted:
- use of
uv syncinstead ofuv pip install, this can cause problems with incompatible depsets - use of
uvdepset definition inpyproject.tomlwhich no longer conforms with PEP
|
|
||
| UV_INSTALL_DIR := ./bin | ||
|
|
||
| # TODO: I don't think we should install uv locally inside the repository, but rather rely on the user having it installed globally. This is because uv is a tool that is meant to be used across multiple projects, and installing it locally in each project can lead to version conflicts and unnecessary duplication. Instead, we can specify in the documentation that users should have uv installed globally, and provide instructions on how to do so if they don't already have it |
fkiraly
left a comment
fkiraly
left a comment
There was a problem hiding this comment.
I see, thanks!
- opinion on
uv syncremains - also, we should not rename
release.yml, since it is registered as a trusted publisher with pypi now. Not uniform, but less of a hassle...
…re that it will rin
2 participants
Homogenizes the main workflows of pyportfolioopt with that of GC.OS repositories - template used is
sktime@fkiraly