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
Revert "docutils: 0.19 → 0.20.1" #249446
Revert "docutils: 0.19 → 0.20.1" #249446
Conversation
This reverts commit 20642ff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will get this done again soon (I hope)!
Might it make more sense to have a I’m currently already using features from the latest version. |
This isn't common practice in our Python packaging because only one version of a dependency can be on PYTHONPATH. (Does OCaml have the same problem?) We do sometimes override versions in consuming applications, however. How are you consuming the latest version, maybe there's a way to accommodate it without changing the common practice. |
mtime is one of those packages I had to deal with recently when getting an OCaml library merged. mtime stays at latest stable. Legacy applications & libraries using an old, unsupported version now use a pinned old version @ mtime_1. According to this (
OCAMLPATH env var.
With applications they are used as a separate buildInput
With libraries, it’s overridden on callPackage nixpkgs/pkgs/top-level/ocaml-packages.nix Line 57 in 1daf129
|
How does OCaml handle the situation when two versions of the same library are asked for in OCAMLPATH? |
Not entirely sure how that scoping or version picking is done. |
Got it, that's the main reason why we currently require only a single version of every library in the package set. I'm sure you can find exceptions that have been justified, and applications can override any library they need to, as nothing depends on them. How are you pulling in the latest version of docutils and using it? |
From staging as a self-made overlay. Could I still use an overlay, yes? But we would be stepping backwards to from a stable version to one that isn’t supported. |
I'm very sorry about this, but the only two ways forward I see are either reverting this or updating sphinx. Used as a library, we need to choose one version of docutils, and we cannot break sphinx; it's at least part of the darwin stdenv bootstrap (it's needed to build LLVM's manpages). I haven't looked into all of the options for fixing sphinx (except that updating it is not trivial). However, if we can resolve that we should be able to try updating docutils again. |
I'll think a little more about if #244625 is the best approach to updating sphinx and try to get it across the finish line soon. |
|
But Docutils is a standalone tool? |
Oh, I see, it's both an application and a library, and you're using the application part. Then it would be possible to update only the application. It's currently defined as:
so it's possible to stop reusing the |
#249518 would do that if it's wanted |
It is a standalone tool and a library. |
@tjni should I close this? |
I think we still need this, it downgrades the library while #249518 updates the application again. |
Reverts #243078
Unfortunately