volta-cli / volta Goto Github PK

Pretty excited about boats' new failure library. Try that out in place of error-chain.

The guid crate is nice and reusable. It could be extracted to a separate repo and published to crates.io. It'll need API docs.

We should respect the cache headers provided by index.json provided by node.

curl -I https://nodejs.org/download/release/index.json

last-modified: Thu, 05 Apr 2018 05:37:38 GMT
etag: "5ac5b622-1bf31"
access-control-allow-origin: *
expires: Fri, 13 Apr 2018 05:44:24 GMT <--- I think we care about this one.
cache-control: public, max-age=14400

In general, they are about a week. But basically always expire before the next Sunday.

Important Scenarios:

1. When the file has expired, and https://nodejs.org/download/release/index.json is accessible, we should download the new artifact, and replace it with the exist.
2. When the file hasn't expired, use the cached version.
3. to support concurrent accesses of this file, we should be sure to update the cached file atomically.

notion_core::launch::script_command is unimplemented.

We now have a reasonable amount of API doc comments, and I would like to start publishing them on a subdomain of notionjs.com. The URL structure I think I would like to use is:

https://impl.notionjs.com/$version/$variant/*
https://impl.notionjs.com/latest/$variant/*
https://impl.notionjs.com/$variant/*

where $version is maybe just "$major.$minor", $variant is either "windows" or "unix", latest is an alias for the current max available version, and the last form is just a shorthand for latest.

Since these are internal docs, I'd like to include all private definitions. I learned recently that the way to do this is currently nonobvious (I've reached out to some Cargo folks about getting a more standard command-line option in cargo doc for this):

% RUSTDOCFLAGS=--document-private-items cargo doc --all --no-deps

We'll want automation in both Appveyor and Travis to generate both the Windows and Unix versions (which do differ in a small number of important places!).

We should be testing in Unix with Travis.

Eliminate all FIXME comments and file them as issues.

notion_core::installer::node::Installer::remote() should put a TeeReader around its input source to save the results to a cache file. The cache file should be stored in a directory specified by notion_core::path::node_cache_dir().

It might be nice to streamline the build/deploy process to use cargo-wix for generating the Windows installer instead of the current command scripts.

Path to eliminating the hand-written logic for version data structures and for serialization of various data structures:

• config should use serde (with an IR if necessary)
• config should match the structure of RFC1 — just one hook for now
• catalog should store versions as an ordered, sorted collection
• catalog should support a resolve method that finds an available version that matches a spec
• move most Tool logic to Node, for now tailored to specifically being the Node launcher
• create a new top level Node launcher separate from launchbin/launchscript
• rename notion/main.rs to notion/notion.rs
• Node::new() should call session.node(&mut self) and get back the Version, instead of session.node_version()
• session.node() should check for project and if so get a VersionReq, otherwise use the current catalog Version
• when session.node() gets a VersionReq, try to find one already in catalog and return that
• when session.node() gets a VersionReq and there’s none in catalog, either use resolution plugin or default resolution logic
• config should have an IR for serialization
• default resolution logic should consult https://nodejs.org/dist/index.json but for now can hard-code a few versions
• plugin resolution logic should call the executable
• manifest should parse using serde
• manifest should just return the VersionReq
• remove the logic of installing from Manifest
• kill the lockfile module entirely
• kill the untoml module entirely
• kill the version module entirely
• session.install_node() should ask the catalog to do the fetching if it has a VersionReq
• catalog should initiate the plugin’s resolution protocol if it needs to resolve a VersionReq

WIP, will flesh this out later:

What?

We should consider abiding by the XDG Base Directory Specification

This makes where notion lives on disk configurable, specifically it would abide by the following ENV variables:

• $XDG_DATA_HOME fallback: $HOME/.local/share

• $XDG_CONFIG_HOME fallback: $HOME/.config

• $XDG_DATA_DIRS fallback: /usr/local/share/:/usr/share/

• $XDG_CONFIG_DIRS fallback: /etc/xdg

• $XDG_CACHE_HOME fallback: $HOME/.cache

• $XDG_RUNTIME_DIR fallback see [spec]((https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html)

• more details for each are specified here*

Why?

• cluttering up $HOME becomes unwieldy
• simplifies testing (we can sub-shell and simply set up the appropriate $XDG vars (no chroot, containers etc)
• easier to reset config / clear caches
• power users can configure to there hearts content, but no cost those who wish to rely on the fallbacks

How

Technically, likely via the XDG crate

Others Using XDG

Mostly just a list of whats in my $XDG_CONFIG_HOME, I suspect there are more.

• nvim: neovim/neovim#3470
• asciinema
• alacritty
• git
• htop
• yarn
• fish
• fisherman

Unresolved

Where do we put stuff in windows?

Maybe something like:

C:\Users\<username>\AppData\Local\notion-cli\notion\{dirs...}

Need basic functionality for reading user/system configuration. This is where plugins get installed. Should have a basic precedence algorithm for being able to consult the project directory and then the user's configuration directory.

The readme needs a high-level explanation of shims.

The verbatim crate only has enough implemented to work on a couple manual test cases. It needs to be completed.

And probably extracted into a separate repo and published to crates.io!

We should be testing in Windows with appveyor.

The notion-core crate is getting pretty unwieldy. A possible reorg to make it a little easier to get a handle on:

installer/

serial/

state/
  path/
    unix.rs
    windows.rs
  catalog.rs
  config.rs
  plugin.rs

shell/
  env.rs
  style.rs

project/
  manifest.rs
  mod.rs // was: project.rs

exec/
  session.rs
  tool.rs

lib.rs

When there's an error in a config file, Volta should print out not just the error message but the relevant lines in the actual source code.

This will require maintaining source location information in the parsers, some of which may not be available from the crates we're currently using. So this one could end up being blocked on getting more full-featured TOML and JSON parsers.

We should publish Linux installers in apt.

There should be a single module that contains a full encyclopedia of exit codes, and all the error types throughout notion-core and the main crate should pull their exit codes from that module.

Thanks to @benblank we have an exit codes RFC!

Every user should have permissions to add shims to the shim/ directory. In Windows since this is in a shared directory, the installer needs to set permissions on that directory to be world-writeable.

We should publish Linux installers as rpms.

The installer doesn't have any UI with it. It would make a more pleasant onboarding experience to see a welcome message and a logo, even though there aren't any particular decisions for the user to make.

Need to set up a decent acceptance test harness.

We should publish Windows releases with chocolatey.

We should generate the msi and deploy it via GitHub releases in the appveyor automation.

How should notion behave for the npm link usecase?

Imagine project A uses node@6 and project B uses node@8 with project B depending on A

The workflow used would be:

1. cd projectA
2. npm link to make it globally available
3. cd projectB
4. npm link projectA to link it up.

The npm versions used in 2 and 4 are different and will cause B not to find A

At least the modules, crates, and primary abstractions should have decent rustdoc comments for MVP.

The winfolder crate only has a handful of folders that I needed for the first demo of Notion. It should be finished with the complete set of standard Windows folders.

It should probably also be extracted into its own separate repo and published to crates.io!

Anything that parses user input, including semver::{Version, VersionReq} parsing, should produce user-friendly error messages on failure.

We need to tighten up the error handling strategy to be sure we always communicate a high-quality error message.

notion_core::manifest::resolve_node should consult config file for hooks.

This blocks issue #4.

We can't currently do streaming reads from Zip files -- there's an open PR on this for zip-rs but it's been stalled for quite some time.

Until we have a solution to this, we should show a progress spinner in the UI.

style::progress_bar currently has a hard-coded size of 40, but should be sized dynamically based on the terminal size (which can be computed via the term_size crate).

Need an installation shell script for Mac/Linux installation.

NodeCatalog::resolve_public scans for available version of node from the public list, but it doesn't make sure each version it checks is actually available for the current OS. Add this logic to the skip_while callback.

This is a tracking issue for the RFC "Node version resolution".

I believe fetching the public node listing is causing a pause with no visible indication to the user. Test this hypothesis, and if it's true, we should:

• show an activity and/or progress indicator while fetching it
• possibly cache it

I'm not sure if the caching semantics works, since it could mean missing new versions. So we should think that through.

A project without "notion" in its manifest should be treated not as an error but as a project that hasn't opted into using Notion. So in this case it should back off to analogous behavior to existing Node managers, i.e., it should use the globally selected toolchain.

Notion should download and cache the latest version of yarn.

A tarball of the latest version of yarn can be found at https://yarnpkg.com/latest.tar.gz

The version for this is located at https://yarnpkg.com/latest-version, which returns a text string (currently 1.6.0)

From https://yarnpkg.com/en/docs/install#alternatives-stable, this download can be verified like so:

wget -qO- https://dl.yarnpkg.com/debian/pubkey.gpg | gpg --import
wget https://yarnpkg.com/latest.tar.gz.asc
gpg --verify latest.tar.gz.asc
# Look for "Good signature from 'Yarn Packaging'" in the output

For unixes at least, I suspect it would be easier to implement a correct delegation for Tool::exec by using a Unix exec call. But this is an area I need to dig into more. (Expert advice welcome!)

notion_core::provision::by_version should consult a node fetch hook.

This blocks issue #4.

Tool::exec doesn't propagate signals yet.

To avoid the complicated conditionals, the session.node() method should return an enum of which "kind" of Node we got (global vs project). That enum should have a method that produces an Option<Version>.

This maybe wants to be reconciled with the Installed type returned by install_node.

Need an initial implementation for package executables.

See volks73/cargo-wix#42.

TLDR: the termcolor crate is highly portable and supports multiple versions of Windows.

The code for command-line parsing is nasty. Try out a different command-line parsing crate, probably docopt.rs or maybe structopt.

The logic for error reporting and exiting is scattered across the main crate and notion_core. These should be consolidated and unified.

Use ANSI styling (bold green, right-aligned) for the "Installing" action in the progress bar.

The Windows installer isn't properly deleting the Node installation directories on uninstall.

We should publish Mac installers as formulae in homebrew.