Ugrade base system to Ubuntu 24.04 #1067
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -40,9 +40,11 @@ RUN apt-get update && DEBIAN_FRONTEND="noninteractive" apt-get install -y --no-i | |
| xlsx2csv \ | ||
| gh \ | ||
| nodejs \ | ||
| npm \ | ||
| graphviz \ | ||
| python3-psycopg2 \ | ||
| swi-prolog \ | ||
| libpcre3 | ||
|
|
||
| # Install run-time dependencies for Soufflé. | ||
| RUN DEBIAN_FRONTEND="noninteractive" apt-get install -y --no-install-recommends \ | ||
|
|
@@ -95,7 +97,7 @@ COPY scripts/obodash /tools | |
| RUN chmod +x /tools/obodash && \ | ||
| git clone --depth 1 https://github.com/OBOFoundry/OBO-Dashboard.git && \ | ||
| cd OBO-Dashboard && \ | ||
| python3 -m pip install -r requirements.txt --break-system-packages && \ | ||
|
There was a problem hiding this comment.
I wonder if this is very suboptimal and we should, instead, install OBO dashboard as a pypi package and install it the usual way? Why is There was a problem hiding this comment. What are the break system packages? I can update to the latest version, if possible. There was a problem hiding this comment.
We could, but then we would need actual releases of the OBO Dashboard package whenever we want to update it in the ODK. For now, the OBO Dashboard is effectively working in a “rolling release” fashion: it doesn’t do releases and we always install it from the tip of the master branch. That would need to change. There was a problem hiding this comment.
What do you mean? We are not breaking anything. The option is named like this as a rather condescending way of telling end-users that they should not try to install anything in the system-wide directory, because if they do they run the risk of introducing a conflict between packages that have been installed there by the distribution (packages installed with But in a Docker image, we mostly don’t care about that risk, since when the image is built, the system-wide directory is in effect read-only. Once we are done installing whatever we need in it, nobody will ever modify that directory ever again. There was a problem hiding this comment.
I can create a release right now. There was a problem hiding this comment.
Because in |
||
| echo " " >> Makefile && \ | ||
| echo "build/robot.jar:" >> Makefile && \ | ||
| echo " echo 'skipped ROBOT jar download.....' && touch \$@" >> Makefile && \ | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| FROM ubuntu:24.04 | ||
| LABEL maintainer="[email protected]" | ||
|
|
||
| ENV ROBOT_VERSION=1.9.6 | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| FROM ubuntu:24.04 | ||
| LABEL maintainer="[email protected]" | ||
|
|
||
| WORKDIR /tools | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -778,7 +778,7 @@ class ExecutionContext(JsonSchemaMixin): | |
| project : Optional[OntologyProject] = None | ||
| meta : str = "" | ||
|
|
||
|
|
||
| @dataclass | ||
| class Generator(object): | ||
| """ | ||
|
|
@@ -787,7 +787,7 @@ class Generator(object): | |
| """ | ||
|
|
||
| ## TODO: consider merging Generator and ExecutionContext? | ||
| context : ExecutionContext = field(default_factory=ExecutionContext) | ||
|
There was a problem hiding this comment. Is this because of the newer dataclass version in the newer python? There was a problem hiding this comment. Yes. The other fix that the |
||
|
|
||
| def generate(self, input : str) -> str: | ||
| """ | ||
|
|
@@ -1083,7 +1083,7 @@ def seed(config, clean, outdir, templatedir, dependencies, title, user, source, | |
| print(" 5. See the section under '…or push an existing repository from the command line'") | ||
| print(" E.g.:") | ||
| print("cd {}".format(outdir)) | ||
| print("git remote add origin [email protected]:{org}/{repo}.git".format(org=project.github_org, repo=project.repo)) | ||
| print("git branch -M {branch}\n".format(branch=project.git_main_branch)) | ||
| print("git push -u origin {branch}\n".format(branch=project.git_main_branch)) | ||
| print("BE BOLD: you can always delete your repo and start again\n") | ||
|
|
||
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.
Your commit messages are great, but it's important to avoid using offensive language in them. Thank you!
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.
Sorry but I won’t take lessons in how to write commit messages from folks who can’t be bothered to write decent commit messages themselves.
If people complain about an occasional profanity in one of my commit messages, at least I will know that there are some people who read them.
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.
Correct me if I am wrong but I dont think this was meant as a lesson, more like a statement of affectedness.
I also prefer to avoid strong language in the spirit of conduct (as the Covenant Code of Conduct suggests), I had endless discussions of misconduct in some other projects which just distract from our common goals.
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.
My pleasure.
A “statement of affectedness” would have been something like, “I felt offended by the presence of that F-word, I don’t like reading such things when I am reviewing a PR. I’d appreciate if you abstained to do that“ or similar.
“It’s important to avoid using offensive language in [commit messages]” is absolutely a lesson in how one should write a commit message – one that I find hard to accept coming from someone who I can’t remember having ever seen write a single decent commit message that actually explains what they are trying to do.
The ODK does not have a code of conduct. Maybe it should (though I’d much rather have a “code on how to write efficient commit messages so that future contributors don’t have to guess what the f... the developers had in mind when they committed that change”, but it’s OK, we can have different priorities), but currently it does not.
Even if it had, according to the most popular code of conducts in use out there, the correct response to the occasional use of inappropriate language is a “private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate” – not a public rebuke.
Fine. I hereby publicly apologise for having expressed my state of mind, as to why I believe installing the OBO Dashboard in a virtual environment just to circumvent
pip’s default behaviour would be a unnecessary complication, using a 6-letters profanity instead of a more elaborate, professional, and polite phrasing. I did that for the sake of efficiency, but I didn’t consider that indeed people might not want to read a F-word when they are busy reviewing a PR.I hope this will end the current distraction, and I will temporarily withdraw for all ODK maintenance to be sure you are not distracted again.