@fkiraly I don't plan to remove, but those are the ones causing problems with uv. I asked @marrov and @jgyasu on Discord, and also on uv issues, waiting for replies.

Do you have any problem if we rename these? I think dependencies prefix is the culprit.

And while we are ln the topic, do we really need to keep supporting pandas1, all_extras, etc.? I know I asked this repetitively, but we need to decide when to stop supporting such old versions.

Do you have any problem if we rename these? I think dependencies prefix is the culprit.

I have no problem with renaming these, but this would seem very odd.
Why are dependency sets starting with dependencies_ treated differently?

Is this a bug in uv after all?

Do you have any problem if we rename these? I think dependencies prefix is the culprit.

I have no problem with renaming these, but this would seem very odd. Why are dependency sets starting with dependencies_ treated differently?

Is this a bug in uv after all?

I can not say. I've created astral-sh/uv#16118 to get some clarity. Even currently when I commented those two extras, there are conflicting extras/groups but it's not failing. That's what make me think there may be some regex pattern or something, or some configuration I am missing. Not familiar enough with uv ecosystem.

FYI @sktime/core-developers

Conflicts detected by uv

Conflict 1

  × No solution found when resolving dependencies:                                                                                 
  ╰─▶ Because sktime[dependencies-lower] depends on numpy==1.25.0 and sktime[dependencies-lowest] depends on numpy==1.21.0, we
      can conclude that sktime[dependencies-lowest] and sktime[dependencies-lower] are incompatible.
      And because your project requires sktime[dependencies-lower] and sktime[dependencies-lowest], we can conclude that your
      project's requirements are unsatisfiable.

Conflict 2

  × No solution found when resolving dependencies for split (included: sktime[dependencies-lowest]; excluded:                      
  │ sktime[dependencies-lower]):
  ╰─▶ Because sktime[all-extras] depends on skforecast>=0.15 and only the following versions of skforecast are available:
          skforecast<=0.15.0
          skforecast==0.15.1
          skforecast==0.16.0
          skforecast==0.17.0
          skforecast==0.18.0
      we can conclude that sktime[all-extras] depends on skforecast>=0.15.
      And because skforecast>=0.15.0 depends on numpy>=1.24 and sktime[dependencies-lowest] depends on numpy==1.21.0, we can       
      conclude that sktime[dependencies-lowest] and sktime[all-extras] are incompatible.
      And because your project requires sktime[all-extras] and sktime[dependencies-lowest], we can conclude that your project's    
      requirements are unsatisfiable.

Conflict 3

  × No solution found when resolving dependencies for split (included: sktime[dependencies-lowest]; excluded: sktime[all-extras],  
  │ sktime[dependencies-lower]):
  ╰─▶ Because sktime[all-extras-pandas2] depends on skforecast>=0.15 and only the following versions of skforecast are available:
          skforecast<=0.15.0
          skforecast==0.15.1
          skforecast==0.16.0
          skforecast==0.17.0
          skforecast==0.18.0
      we can conclude that sktime[all-extras-pandas2] depends on skforecast>=0.15.
      And because skforecast>=0.15.0 depends on numpy>=1.24 and sktime[dependencies-lowest] depends on numpy==1.21.0, we can       
      conclude that sktime[dependencies-lowest] and sktime[all-extras-pandas2] are incompatible.
      And because your project requires sktime[all-extras-pandas2] and sktime[dependencies-lowest], we can conclude that your      
      project's requirements are unsatisfiable.

Conflict 4

  × No solution found when resolving dependencies for split (markers: python_full_version >= '3.12'; included:
  │ sktime[dependencies-lowest]; excluded: sktime[all-extras-pandas2], sktime[all-extras], sktime[dependencies-lower]):
  ╰─▶ Because only freia{python_full_version < '3.12'}==0.2 is available and freia==0.2 depends on scipy>=1.5, we can conclude
      that all versions of freia{python_full_version < '3.12'} depend on scipy>=1.5.
      And because sktime[dl] depends on freia{python_full_version < '3.12'} and sktime[dependencies-lowest] depends on
      scipy==1.4.0, we can conclude that sktime[dl] and sktime[dependencies-lowest] are incompatible.
      And because your project requires sktime[dependencies-lowest] and sktime[dl], we can conclude that your project's
      requirements are unsatisfiable.

Conflict 5

  × No solution found when resolving dependencies for split (markers: python_full_version >= '3.12'; included:
  │ sktime[dependencies-lowest]; excluded: sktime[all-extras-pandas2], sktime[all-extras], sktime[dependencies-lower],
  │ sktime[dl]):
  ╰─▶ Because skforecast>=0.15.0 depends on scikit-learn>=1.2 and only the following versions of skforecast are available:
          skforecast<=0.15.0
          skforecast==0.15.1
          skforecast==0.16.0
          skforecast==0.17.0
          skforecast==0.18.0
      we can conclude that skforecast>=0.15.0 depends on scikit-learn>=1.2.
      And because sktime[forecasting] depends on skforecast>=0.15 and sktime[dependencies-lowest] depends on
      scikit-learn==0.24.0, we can conclude that sktime[forecasting] and sktime[dependencies-lowest] are incompatible.
      And because your project requires sktime[dependencies-lowest] and sktime[forecasting], we can conclude that your project's   
      requirements are unsatisfiable.

Conflict 6

  × No solution found when resolving dependencies for split (markers: python_full_version >= '3.12' and sys_platform != 'win32';   
  │ included: sktime[dependencies-lowest]; excluded: sktime[all-extras-pandas2], sktime[all-extras], sktime[dependencies-lower],
  │ sktime[dl], sktime[forecasting]):
  ╰─▶ Because pytorch-forecasting<=0.7.1 depends on scikit-learn>=0.23,<0.24 and only the following versions of
      pytorch-forecasting are available:
          pytorch-forecasting==0.1.0
          pytorch-forecasting==0.1.1
          pytorch-forecasting==0.1.2
          pytorch-forecasting==0.2.0
          pytorch-forecasting==0.2.1
          pytorch-forecasting==0.2.2
          pytorch-forecasting==0.2.3
          pytorch-forecasting==0.2.4
          pytorch-forecasting==0.3.0
          pytorch-forecasting==0.3.1
          pytorch-forecasting==0.4.0
          pytorch-forecasting==0.4.1
          pytorch-forecasting==0.5.0
          pytorch-forecasting==0.5.1
          pytorch-forecasting==0.5.2
          pytorch-forecasting==0.5.3
          pytorch-forecasting==0.6.0
          pytorch-forecasting==0.6.1
          pytorch-forecasting==0.7.0
          pytorch-forecasting==0.7.1
          pytorch-forecasting==0.8.0
          pytorch-forecasting==0.8.1
          pytorch-forecasting==0.8.2
          pytorch-forecasting==0.8.3
          pytorch-forecasting==0.8.4
          pytorch-forecasting==0.8.5
          pytorch-forecasting==0.9.0
          pytorch-forecasting==0.9.1
          pytorch-forecasting==0.9.2
          pytorch-forecasting==0.10.0
          pytorch-forecasting==0.10.1
          pytorch-forecasting==0.10.2
          pytorch-forecasting==0.10.3
          pytorch-forecasting==1.0.0
          pytorch-forecasting==1.1.0
          pytorch-forecasting==1.1.1
          pytorch-forecasting==1.2.0
          pytorch-forecasting==1.3.0
          pytorch-forecasting==1.4.0
          pytorch-forecasting==1.5.0
      we can conclude that pytorch-forecasting<0.8.0 depends on scikit-learn>=0.23,<0.24. (1)

      Because optuna>=2.3.0,<=2.10.1 depends on one of:
          scipy<1.4.0
          scipy>1.4.0
      and only the following versions of optuna are available:
          optuna<=2.3.0
          optuna==2.4.0
          optuna==2.5.0
          optuna==2.6.0
          optuna==2.7.0
          optuna==2.8.0
          optuna==2.9.0
          optuna==2.9.1
          optuna==2.10.0
          optuna==2.10.1
          optuna>3.0.0
      we can conclude that optuna>=2.3.0,<3.0.0 depends on one of:
          scipy<1.4.0
          scipy>1.4.0

      And because pytorch-forecasting>=0.8.0,<=0.10.3 depends on optuna>=2.3.0,<3.0.0, we can conclude that
      pytorch-forecasting>=0.8.0,<=0.10.3 depends on one of:
          scipy<1.4.0
          scipy>1.4.0

      And because we know from (1) that pytorch-forecasting<0.8.0 depends on scikit-learn>=0.23,<0.24, we can conclude that        
      pytorch-forecasting<1.0.0, all of:
          scikit-learn<0.23
          scikit-learn>=0.24
      , scipy==1.4.0 are incompatible.
      And because pytorch-forecasting>=0.10.2 depends on scipy>=1.8 and sktime[notebooks] depends on pytorch-forecasting, we can   
      conclude that all of:
          scikit-learn<0.23
          scikit-learn>=0.24
      , scipy==1.4.0, sktime[notebooks] are incompatible.
      And because sktime[dependencies-lowest] depends on scipy==1.4.0 and your project depends on scikit-learn>=0.24, we can       
      conclude that your project, sktime[notebooks], sktime[dependencies-lowest] are incompatible.
      And because your project requires sktime[dependencies-lowest] and sktime[notebooks], we can conclude that your project's     
      requirements are unsatisfiable.

Conflict 7

  × No solution found when resolving dependencies for split (included: sktime[all-extras-pandas2], sktime[all-extras],
  │ sktime[dependencies-lower], sktime[dl], sktime[forecasting], sktime[notebooks]; excluded: sktime[dependencies-lowest]):
  ╰─▶ Because sktime[dependencies-lower] depends on pandas==2.0.2 and sktime[pandas1] depends on pandas<2.0.0, we can conclude
      that sktime[pandas1] and sktime[dependencies-lower] are incompatible.
      And because your project requires sktime[dependencies-lower] and sktime[pandas1], we can conclude that your project's
      requirements are unsatisfiable.

FYI @Abelarm for your related PR.

Does uv not allow mutually contradictory dependency sets? This makes sense for testing on pins as we currently do, but it seems like it would be prevented?

It allows, and the current configuration explicitly notes what all are contradictory. See tool.uv.conflicts section.

what, if any, is the impact of moving the build backend to our users?

For sktime users (and not contributors), the effect is none. This is my experience with respect to my personal play project and new work POC's. @marrov mentioned on Discord of doing migration in all of their production environments and can add details.

does this cause a breaking change or not, in package setup or package usage?

No effect for sktime users.

I think this is still problematic in its current state given the above.

@fkiraly can you please elaborate? What changes seem problematic to you? If you are talking about the CI failures, the errors seem very constrained to classification/regression/networks and failure make it very clear that this is source code and/or unit test issue, not related to package build backend.

I think this is still problematic in its current state given the above.

Lack of clarity on the impact is my greatest concern.

For sktime users (and not contributors), the effect is none.

What is the impact on contributors? Would pip install -e . still work, or not, for instance?
Why are you qualifying your reply like this, can you give more info on the impact on contributors?

does this cause a breaking change or not, in package setup or package usage?

No effect for sktime users.

How do you know?

Do you have any problem if we rename these? I think dependencies prefix is the culprit.

Regarding clarity: for instance, you claimed above we have to remove the dependency sets starting with dependencies because they have some special meaning in uv. I think based on the more recent changes it turned out to be untrue.

That is one indication that tells me we are not entirely certain about the impact of this change, simply since you - who are proposing the change - are also not with certainty familiar with uv.

Whereas the change is happening at such a central place in the delivery and release pipeline that even a small unmanaged problem could become catastrophic and go unnoticed for a while.

So we need to be absolutely sure we understand what we are doing here, and the back/forth about the conflicting dependencies is not filling me with confidence.

Do you have any problem if we rename these? I think dependencies prefix is the culprit.

Regarding clarity: for instance, you claimed above we have to remove the dependency sets starting with dependencies because they have some special meaning in uv. I think based on the more recent changes it turned out to be untrue.

That is one indication that tells me we are not entirely certain about the impact of this change, simply since you - who are proposing the change - are also not with certainty familiar with uv.

I do not claim to be 100% expert on uv. We learn by trying new things and asking experience people (in this case uv members) for guidance. Do you claim 100% knowledge for conda or conda-forge? Do you not release sktime and related packages on conda? Do you not have multiple git detection based test PR's that broke things and then we identified later and fixed? It's open source and we may not know something and over time we learn and improve, and I don't see why my initial incorrect inference have to become the determining factor.

I've not made the PR ready for review without satisfying myself. I've also requested uv members to review if they have bandwidth for suggestions, they can guide us. If you have a specific technical issue that you face while trying to use this branch, or a specific situation where you think it won't work, please do share and I am happy to discuss how to solve it. Others people more experienced with uv can also help.

How do you know?

sktime is not the only package I use, and as part of my work where multiple build backends are used. The fact that majority of CI passed (except where test issues are there is few specific cases), it proves that it is working. In Discord @marrov as well mentioned similar migration experiences and lots of packages are doing migration for performance benefits, sktime package building process is not out of ordinary.

I'll request other @sktime/core-developers and @sktime/community-council members (and all contributors/users) to also share their opinion/concern on user impact by build backend change. It's completely fine of course if we decide to say let's not change, but that is a decision that should be taken based on testing and specific scenarios and #6288 then needs to be closed as not planned or etc. accordingly.

Hi @yarnabrina and @fkiraly ,

In the optics of moving to lockfiles, I think this PR is necessary; Even more is the cornerstone to the whole "move towards a more robust dependencies resolution".

In order to move it to fully uv as project management, I think we need more than just change pyproject.toml.

For my side, here is the (partial)list of task we need to compete before moving to "lockfile-based approach" (uv):

• Choose if we we utilize uv.lock o pylock.toml pylock.toml
  I would choose the latter because it's tool agnostic and it's supported by both pip and uv
• Update all the CI to utilize the sync command instead of the pip install
• Update the documentation for developers on how to install sktime from source in "editable"
• Add a pre-commit check checking if the lock is still valid
  Alternative: Add a pre-commit to automatically update the lock (if pyproject.toml is different to the lock one)

I am really happy to help with whatever, and let me know if I missed something.

hm, I would not want to require a change in developer commands from pip to uv.
pip is still the standard and most interoperable of all package managers.

Have we discussed strategy on uv in an issue yet? E.g., what we migrate, what we keep. E.g., CI, packaging backend, developer workflow, etc.

hm, I would not want to require a change in developer commands from pip to uv.
pip is still the standard and most interoperable of all package managers.

I completely agree and I don't want to get rid of pip, for this reason I suggested pylock.toml which is PEP-solution for lockfile and it's supported by both pip and uv.

In a way or another if we move to lock files we need to update the developer commands anyway. (that's what I meant with my third point)

Have we discussed strategy on uv in an issue yet? E.g., what we migrate, what we keep. E.g., CI, packaging backend, developer workflow, etc.

In my opinion we(you) need to decide what you want to achieve:

• Speed-up of CI (already merged by my PR: pip -> uv pip )
• Use a *.lock file approach (decide what platform uv sync, pip compile, poetry, etc etc)
• Use uv as build backend (this PR)
• Use uv as project management (partially this PR)

Maybe as you are suggesting we should open an Issue, or a discussion on any other platform for deciding the approach.

My understanding was that the changes I've made in this PR changes the build backend from setuptools to uv-build. No changes in this PR should affect pip interface to install/uninstall at all for end users of sktime who so far are using pip install sktime or pip install sktimne[...] etc. Based on all the debates, now I'm confused, @fkira;y @Abelarm are you saying this is not the case and that flow gets affected? If so, can you please elaborate why and how?

If you agree with me, then the only people that gets affected are contributors or someone using sktime, and the issue they will face is with uv.lock file. If we do not enforce contributors to use uv, then non-uv people will not be able to update uv.lock files in case they made any changes pyproject.toml. Do you expect them to face changes beyond this case? If we take @marrov 's suggestion to not track uv.lock file, then will this not be resolved?

I am also somewhat confused. I think we need to write down exactly the workflows (user or developer) that we are considering, the changes we are proposing, and how the workflows will be affected (or not).

I am also somewhat confused. I think we need to write down exactly the workflows (user or developer) that we are considering, the changes we are proposing, and how the workflows will be affected (or not).

Requesting review, and comments on what other common workflow you are thinking of.

# Expected `pip` workflows and effect of switching from `setuptools` to `uv-build` as build backend

## By `sktime` users

1. install from PyPI
   * Old: `pip install sktime`
   * New: `pip install sktime`
2. same but with additional optional dependencies 
   * Old: `pip install sktime[forecasting]`
   * New: `pip install sktime[forecasting]`

In both cases, users will get the same pre-built wheels from PyPI as before. The `uv` pip interface is optional; if desired, users may use `uv add sktime` (see the `uv` docs).

## By `sktime` contributors

1. install from local source code
   * Old: `pip install .` from the root of the repository
   * New: `pip install .` from the root of the repository
2. same but in editable mode
   * Old: `pip install -e .` from the root of the repository
   * New: `pip install -e .` from the root of the repository

In both cases, contributors will get the same behaviour as before. Contributors may optionally use the `uv` CLI for similar workflows.

If contributors modify `pyproject.toml` to add or remove optional dependencies, those changes will be respected by both build backends.

Tracking a `uv.lock` file is optional. If we do track it, the lock records exact dependency versions and CI can use `uv sync` to reproduce builds. Contributors who change `pyproject.toml` must regenerate the lock with `uv lock` and commit the update. Contributors who do not use `uv` locally will not be able to regenerate the lock easily; this is an optional reproducibility feature and is not required to use `uv-build`. `pip` (or `uv pip`) will continue to install the latest compatible versions unless a lockfile is used.

## By `sktime` maintainers

1. build from source code
   * Old: `python -m build`
   * New: `uv build`
2. upload to PyPI
   * Old: `twine upload dist/*`
   * New: `twine upload dist/*`

In both cases, maintainers will get the same behaviour as before. Note that `uv build` and `uv publish` are also available as optional alternatives.

@fkiraly any idea why is CI not running even after 10 hours? On sunday test all runs, but it didn't usually take this much time, especially after the optimisations (and just checked, even that's not running and waiting for something else).

My understanding was that the changes I've made in this PR changes the build backend from setuptools to uv-build. No changes in this PR should affect pip interface to install/uninstall at all for end users of sktime who so far are using pip install sktime or pip install sktimne[...] etc. Based on all the debates, now I'm confused, @fkira;y @Abelarm are you saying this is not the case and that flow gets affected? If so, can you please elaborate why and how?

If you agree with me, then the only people that gets affected are contributors or someone using sktime, and the issue they will face is with uv.lock file. If we do not enforce contributors to use uv, then non-uv people will not be able to update uv.lock files in case they made any changes pyproject.toml. Do you expect them to face changes beyond this case? If we take @marrov 's suggestion to not track uv.lock file, then will this not be resolved?

You are right let's not mix topics, this PR is just for moving the build backend from setuptools to uv, which I think is the correct approach (I will open an Issue talking about the lockfile approaches).

Requesting review, and comments on what other common workflow you are thinking of.

Where you able to test both new and old?
Because I have a question:

"How will pip behave with the uv specific changes you made to the pyproject?"
(e.g all the [tool.uv] fields?)

Where you able to test both new and old?

Yes. At least on my system. But it must be verified on at least one other system.

"How will pip behave with the uv specific changes you made to the pyproject?"
(e.g all the [tool.uv] fields?)

My understanding that it'll be simply ignored by pip and it's not an issue. The conflict declaration is just for valodation. For users, build backend uv will take care of this and user deals with whl file only. For contributors, editable installs won't matter on exclusion logic. For maintainers, pip doesn't relate to build/publish and I checked python -m build still works. Of course need to be reproduced.

@sktime/core-developers please do share your thoughts/notes on the above comparison, reproduction, testing , etc.

Bumping this @sktime/core-developers . Any specific comments/concerns?

A bit of an aside from the core discussion here, but this pull request

• Does not close the linked issue — you're still using pip in CI, this just allows uv to create a lock file
• Does not migrate away from setuptools — that'd look like main...zanieb:sktime:zb/setuptools-uv — your build system is entirely independent of which frontend you're using, i.e., you can use uv-build with pip or setuptools with uv

You might want to update the title / pull request body to clarify given the changes?

A bit of an aside from the core discussion here, but this pull request

• Does not close the linked issue — you're still using pip in CI, this just allows uv to create a lock file
• Does not migrate away from setuptools — that'd look like main...zanieb:sktime:zb/setuptools-uv — your build system is entirely independent of which frontend you're using, i.e., you can use uv-build with pip or setuptools with uv

You might want to update the title / pull request body to clarify given the changes?

Hi @zanieb the mismatch between title and implementation is real. My goal was to fully migrate, including build system to uv build but there's multiple long discussions on Discord at the end of which @fkiraly suggested to only make pyproject.toml uv compatible (so that is any contributor want to use uv sync they don't get blocked) and not make the migration. This was reverted yesterday: 527c069.

Anyway, I'll mark this PR as draft for now till the new PR is finalised.