-
Notifications
You must be signed in to change notification settings - Fork 98
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
Add support for Ubuntu 18.04 to installer #1231
Changes from 3 commits
9c4b58c
3b45ffd
df5393f
172cfd6
9d7d6f5
388d920
af7b12d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ include = ["/src", "/build.rs", "/rust-toolchain.toml", "/LICENSE-*", "/README.m | |
[dependencies] | ||
anyhow = "1" | ||
home = "0.5" | ||
os_info = { version = "3", default-features = false } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. cargo uses |
||
|
||
[[bin]] | ||
name = "kani" | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
# Copyright Kani Contributors | ||
# SPDX-License-Identifier: Apache-2.0 OR MIT | ||
|
||
# Note: this file is intended only for testing the kani release bundle | ||
|
||
FROM ubuntu:18.04 | ||
ENV DEBIAN_FRONTEND=noninteractive \ | ||
DEBCONF_NONINTERACTIVE_SEEN=true | ||
RUN apt-get update && \ | ||
apt-get install -y python3 python3-pip curl ctags && \ | ||
curl -sSf https://sh.rustup.rs | sh -s -- -y | ||
ENV PATH="/root/.cargo/bin:${PATH}" | ||
|
||
WORKDIR /tmp/kani | ||
COPY ./tests ./tests | ||
COPY ./kani-latest-x86_64-unknown-linux-gnu.tar.gz ./ | ||
# Very awkward glob (not regex!) to get `kani-verifier-*` and not `kani-verifier-*.crate` | ||
COPY ./target/package/kani-verifier-*[^e] ./kani-verifier | ||
RUN cargo install --path ./kani-verifier | ||
RUN cargo-kani setup --use-local-bundle ./kani-latest-x86_64-unknown-linux-gnu.tar.gz |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,6 +15,7 @@ | |
#![warn(clippy::all, clippy::cargo)] | ||
|
||
mod cmd; | ||
mod os_hacks; | ||
mod setup; | ||
|
||
use std::env; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,44 @@ | ||
// Copyright Kani Contributors | ||
// SPDX-License-Identifier: Apache-2.0 OR MIT | ||
|
||
//! In order to avoid introducing a large amount of OS-specific workarounds into the main | ||
//! "flow" of code in setup.rs, this module contains all functions that implement os-specific | ||
//! workarounds. | ||
|
||
use std::ffi::OsString; | ||
use std::path::Path; | ||
use std::process::Command; | ||
|
||
use anyhow::Result; | ||
|
||
use crate::cmd::AutoRun; | ||
|
||
/// See [`crate::setup::setup_python_deps`] | ||
pub fn setup_python_deps_on_ubuntu_18_04(pyroot: &Path, pkg_versions: &[&str]) -> Result<()> { | ||
println!("Applying a workaround for 18.04..."); | ||
// https://github.com/pypa/pip/issues/3826 | ||
// Ubuntu 18.04 has a patched-to-be-broken version of pip that just straight-up makes `--target` not work. | ||
// Worse still, there is no apparent way to replicate the correct behavior cleanly. | ||
|
||
// This is a really awful hack to simulate getting the same result. I can find no other solution. | ||
// Example failed approach: `--system --target pyroot` fails to create a `pyroot/bin` with binaries. | ||
|
||
// Step 1: use `--system --prefix pyroot`. This disables the broken behavior, and creates `bin` but... | ||
Command::new("python3") | ||
.args(&["-m", "pip", "install", "--system", "--prefix"]) | ||
.arg(&pyroot) | ||
.args(pkg_versions) | ||
.run()?; | ||
|
||
// Step 2: move `pyroot/lib/python3.6/site-packages/*` up to `pyroot` | ||
// This seems to successfully replicate the behavior of `--target` | ||
// "mv" is not idempotent however so we need to do "cp -r" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we're doing
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I can rename the variable and delete the extra directory, that seems reasonable. |
||
let mut mv_cmd = OsString::new(); | ||
mv_cmd.push("cp -r "); | ||
mv_cmd.push(pyroot.as_os_str()); | ||
mv_cmd.push("/lib/python*/site-packages/* "); | ||
mv_cmd.push(pyroot.as_os_str()); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a risk that the target directory is not writeable (or requires There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope, |
||
Command::new("bash").arg("-c").arg(mv_cmd).run()?; | ||
|
||
Ok(()) | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -33,6 +33,7 @@ pub fn appears_setup() -> bool { | |
/// Sets up Kani by unpacking/installing to `~/.kani/kani-VERSION` | ||
pub fn setup(use_local_bundle: Option<OsString>) -> Result<()> { | ||
let kani_dir = kani_dir(); | ||
let os = os_info::get(); | ||
|
||
println!("[0/6] Running Kani first-time setup..."); | ||
|
||
|
@@ -43,7 +44,7 @@ pub fn setup(use_local_bundle: Option<OsString>) -> Result<()> { | |
|
||
let toolchain_version = setup_rust_toolchain(&kani_dir)?; | ||
|
||
setup_python_deps(&kani_dir)?; | ||
setup_python_deps(&kani_dir, &os)?; | ||
|
||
setup_build_kani_prelude(&kani_dir, toolchain_version)?; | ||
|
||
|
@@ -103,15 +104,26 @@ fn setup_rust_toolchain(kani_dir: &Path) -> Result<String> { | |
} | ||
|
||
/// Install into the pyroot the python dependencies we need | ||
fn setup_python_deps(kani_dir: &Path) -> Result<()> { | ||
fn setup_python_deps(kani_dir: &Path, os: &os_info::Info) -> Result<()> { | ||
println!("[4/6] Installing Kani python dependencies..."); | ||
let pyroot = kani_dir.join("pyroot"); | ||
|
||
// TODO: this is a repetition of versions from kani/scripts/setup/$OS/install_deps.sh | ||
let pkg_versions = &["cbmc-viewer==3.2", "colorama==0.4.3"]; | ||
|
||
if os.os_type() == os_info::Type::Ubuntu | ||
&& *os.version() == os_info::Version::Semantic(18, 4, 0) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is there a risk there will be an 18.4.1? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think there is not a risk of that because I think it's already running on "18.4.4" and not picking that up. I believe what's happening is it's parsing "18.04" as if it were a version number. I agree this is seems fragile but this unit test seems to confirm this is the expected behavior: https://github.com/stanislav-tkach/os_info/blob/master/os_info/src/linux/lsb_release.rs#L317-L318 |
||
{ | ||
crate::os_hacks::setup_python_deps_on_ubuntu_18_04(&pyroot, pkg_versions)?; | ||
return Ok(()); | ||
} | ||
|
||
Command::new("python3") | ||
.args(&["-m", "pip", "install", "cbmc-viewer==3.2", "colorama==0.4.3", "--target"]) | ||
.args(&["-m", "pip", "install", "--target"]) | ||
.arg(&pyroot) | ||
.args(pkg_versions) | ||
.run()?; | ||
|
||
Ok(()) | ||
} | ||
|
||
|
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.
Do we want to get rid of ubuntu-20? Or should we have it as a third option
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.
"get rid of" in what sense? Are you saying not building the regressions (currently 18, 20, and mac) there anymore?
I would sort of endorse that, in that I think we don't need the regressions running on two linux platforms... but what we DO need is "install/smoke testing" running on multiple linux platforms... which is sort of what this is simulating, but it's not good enough yet.
I spent an hour with a whiteboard yesterday trying to sketch out what I thought we'd ideally want to work towards in terms of CI flow and found it a bit frustratingly complicated. I might write up a doc/proposal soon...
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.
@danielsn Note that this is for building the release bundle, and we're building a single bundle for both Ubuntu 18.04 and Ubuntu 20.04.