-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Tezos release 7.0~rc1 #16215
Tezos release 7.0~rc1 #16215
Conversation
Glad to have you here! There's a small bug in the generation scripts I think:
You should only have one level of versioned directory there. It's fine (and encouraged) to set =version for the packages generated from the same repo, as that's how they will be tested together. A tezos metapackage is just fine, and a good user experience ( |
Commit: 321bff7 @pirbo has posted 21 contributions. 🌤️ opam-lint warnings 321bff7
☀️ Installability check (+97)
🌤️ 1 ignored non-opam files:
|
c3414d7
to
8b442fa
Compare
] | ||
build: [ | ||
["dune" "build" "-p" name "-j" jobs] | ||
["mv" "src/proto_006_PsCARTHA/bin_accuser/%{name}%.install" "./"] |
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.
It would be good if you could get rid of this line in the packages. In normal operation, dune build -p
will build only the install file for the package you have requested. Do you need this explicit install override for some other reason? We may be able to just fix that directly in dune if there's an underlying limitation.
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.
Very good question about general organization of the repository. I always wanted to discuss it more broadly with the community without daring :-)
These mv
are necessary because opam files are not at the root of the repository and dune generates .install
files next to their corresponding opam file.
In addition of requiring these ugly mv
, I think (but I'm not sure I wanted to try) that not having the opam files at the root of the repository breaks opam pin add --dev
which is also unfortunate.
On the contrary, as you see the tezos repository defines 97 opam packages so having 97 more files at the root would quite pollute it . Moreover, some part of the code ("economic protocols" in our terminology corresponding to the folders src/proto_*
) are supposed to be (un)pluggable (self contained) plugins, if they are there, software is able to understand/follow the corresponding protocol, if they aren't, you have valid binaries but that don't know about these specific rulesets (but can ask them to their "peers"/compile them/dynamically load them on necessity... an other story). If the opam files corresponding to the libraries of the protocol "foobar" has now to be at the root of the repo, adding/removing protocol "foobar" is not as simple as adding/removing folder src/proto_foobar
anymore and that's annoying.
So I'm confused about what direction to follow...
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.
Hi @pirbo, glad you were able to release tezos here :-)
The next version of opam should add better support for non-toplevel .opam
. See: ocaml/opam#3499 Basically, it allows to add a field subpath
in the package description, meaning: this package only requires this fragment of the .tar.gz
(or the repository) in order to build. So opam
only extracts (or fetch) the required subpath
and build directly in the subdirectory. So, from the dune perspective, both.opam
and .install
are at toplevel.
And, to fix the daily workflow, it adds opam pin add --dev --rec
: il will lookup for .opam
in sub-directories.
I have no idea whenever the next (feature-)release of opam might happen but, meanwhile, maybe this ugly mv
is acceptable. And, maybe, you are the perfect beta-tester for this new feature :-)
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.
Fantastic!
To hear from you first and foremost but also this feature looks to be exactly what we want indeed. No surprise given its original author. :-D
I agree that the mv
are acceptable in the meantime.
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.
I'm not quite convinced that the behaviour of dune is quite correct here, though. If the dune build -p
works, then the semantics of .install
files are that they should be generated at the root of the project to be useful. If you could open up an issue over at https://github.com/ocaml/dune/issues about this, we can take a look at supporting this properly.
We'll be kicking off the opam 2.1 release process in the next weeks, to answer @hnrgrgr's question above. But it would be good to find a solution that'll work with opam 2.0.x as well, since it is widely packaged on OS distributions.
For the record. I'm investigating the test failure of |
This Mac failure is probably sandboxing-related. Are the lmdb tests trying to write somewhere external to the ~/.opam area? |
And we mispelled the constraint anyway
Yes, MacOS failure was related to an hardwired reference to |
Sounds good. I've just triggered a rebuild of this PR to look at the revdeps more closely, as some failed to build due to the volume causing the Docker GC to kick in. |
This broadly all looks good to go now. There are quite a few spurious CI failures, but I double-checked that ledgerwallet-tezos will install on CentOS (I suspect conf-hiadpi needs OpenSUSE depext metadata to install on OpenSUSE, but this isn't a blocker to merge). Do you want to push a non-draft tezos.7 set of packages @pirbo? |
Thank you very much for all your help. |
Look forward to it. Good luck with the release! |
We can finally release software to participate to the Tezos blockchain in opam "central" repository (up to now, binaries were specific to a specific "chain"). 🎉
For now, we follow the policy to add the constraint
{ = version }
in between all the packages part of the same tar.bz2 but we're not sure about that and we welcome feedback...An other question: is it OK to have "meta-package" in the opam-repository? In that case, we would add a package
tezos
with nothing but dependencies to all the binaries (tezos-node, tezos-client, tezos-{accuser,baker,endorser}-006-PsCARTHA) and optional dependencies.