Laboratoria 11 XII

Zajęcia przeprowadzamy w parach.

Każdy potrzebuje własnego konta na Githubie!

Krok 1 (każdy niezależnie)

  1. Tworzymy nowe (prywatne) repozytorium na Githubie na podstawie szablonu: https://github.com/pmikolajczyk41/rust-lang-course-rust-repo.
  2. Postępujemy według poleceń z pliku README.md.
  3. Upewniamy się, że CI przechodzi pomyślnie.

Krok 2: osoba 1.

  1. Tworzymy proste narzędzie z CLI używając biblioteki clap.
  2. Narzędzie powinno posiadać dwie podkomendy: head <n> <file> oraz tail <n> <file>, które mają imitować POSIXowe odpowiedniki. Nie implementujemy logiki komend. W tym kroku zostawiamy tu todo!().
  3. Publikujemy narzędzie na https://crates.io. Tutorial: https://doc.rust-lang.org/cargo/reference/publishing.html.
  4. Weryfikujemy efekty instalując narzędzie poprzez cargo install.

Krok 2: osoba 2. (i 3., jeśli jest nieparzyście wiele osób w grupie)

  1. Tworzymy prostą bibliotekę dostarczającą implementację POSIXowych funkcji: head oraz tail. Innymi słowy, biblioteka wystawia dwie publiczne funkcje: pub fn head(path: &Path, n: usize) -> Vec<String> oraz pub fn tail(path: &Path, n: usize) -> Vec<String> (w razie problemów, na razie panikujemy).
  2. Publikujemy bibliotekę na https://crates.io. Tutorial: https://doc.rust-lang.org/cargo/reference/publishing.html.

Osoba 3. implementuje dwie inne POSIXowe funkcjonalności (np. cp i mv).

Krok 3

  1. (Osoba 1.) Dodajemy bibliotekę partnera do zależności, delegując do niej logikę komend. Publikujemy nową wersję narzędzia.
  2. Pobieramy nową wersję narzędzia i testujemy na lokalnych plikach, czy działa dobrze.

Następne kroki

  1. Dostarczamy dokumentację obu projektów, publikujemy i sprawdzamy na https://docs.rs/
  2. Pogwałcenie zasad semver (https://semver.org/): w bibliotece wprowadzamy niekompatybilność w API (np. zwracamy Result<Vec<String>, String>) i publikujemy podbijając patch version. Instalujemy narzędzie ponownie lub odpalamy cargo update; cargo build w katalogu projektu narzędzia. Powinniśmy zaobserwować błąd kompilacji.
  3. Naprawiamy powyższą sytuację: flaga --locked i yankowanie.
  4. Wprowadzamy nową funkcjonalność w bibliotecę i chowamy ją za feature m. W narzędziu aktualizujemy deklarację zależności.
  5. Dodajemy partnera jako drugiego maintainera projektu (w sensie cargo publish). Testujemy otrzymane pozwolenia.