-
Notifications
You must be signed in to change notification settings - Fork 427
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
No progress indicator for a long time when downloading a project in VSCode #5615
Comments
I think the best solution here is to eagerly print the log lines for dependency resolution. |
👍 And this would not be noisy as long as such print is erased like the building progress bar, or erased and updated to the final print for the finished clone like what is already printed out now. Context: coming from zulip. |
Unfortunately, the solution in #5684 does not have any fancy ANSI updates. There are not many log lines, though, and |
@tydeu No worries, my casual comment was only because I had no idea how many outputs would be there, and whether they are proportional to other informative outputs. Thanks! |
With leanprover/vscode-lean4#542 (still to be released), the progress bar now displays that something is going on in the background more clearly, even when the command doesn't report any output. This doesn't resolve this issue entirely, but it should help a bit. |
Lake will now update a package's `lean-toolchain` file on `lake update` if it finds the package's direct dependencies use a newer compatible toolchain. To skip this step, use the `--keep-toolchain` CLI option. Closes #2582. Closes #2752. Closes #5615. ### Toolchain update details To determine "newest compatible" toolchain, Lake parses the toolchain listed in the packages' `lean-toolchain` files into four categories: release , nightly, PR, and other. For newness, release toolchains are compared by semantic version (e.g., `"v4.4.0" < "v4.8.0"` and `"v4.6.0-rc1" < "v4.6.0"`) and nightlies are compared by date (e.g., `"nightly-2024-01-10" < "nightly-2014-10-01"`). All other toolchain types and mixtures are incompatible. If there is not a single newest toolchain, Lake will print a warning and continue updating without changing the toolchain. If Lake does find a new toolchain, Lake updates the workspace's `lean-toolchain` file accordingly and restarts the update process on the new Lake. If Elan is detected, it will spawn the new Lake process via `elan run` with the same arguments Lake was initially run with. If Elan is missing, it will prompt the user to restart Lake manually and exit with a special error code (4). ### Other changes To implement this new logic, various other refactors were needed. Here are some key highlights: * Logs emitted during package and workspace loading are now eagerly printed. * The Elan executable used by Lake is now configurable by the `ELAN` environment variable. * The `--lean` CLI option was removed. Use the `LEAN` environment variable instead. * `Package.deps` / `Package.opaqueDeps` have been removed. Use `findPackage?` with a dependency's name instead. * The dependency resolver now uses a pure breadth-first traversal to resolve dependencies. It also resolves dependencies in reverse order, which is done for consistency with targets. Latter targets shadow earlier ones and latter dependencies take precedence over earlier ones. **These changes mean the order of dependencies in a Lake manifest will change after the first `lake update` on this version of Lake.**
Lake will now update a package's `lean-toolchain` file on `lake update` if it finds the package's direct dependencies use a newer compatible toolchain. To skip this step, use the `--keep-toolchain` CLI option. Closes leanprover#2582. Closes leanprover#2752. Closes leanprover#5615. ### Toolchain update details To determine "newest compatible" toolchain, Lake parses the toolchain listed in the packages' `lean-toolchain` files into four categories: release , nightly, PR, and other. For newness, release toolchains are compared by semantic version (e.g., `"v4.4.0" < "v4.8.0"` and `"v4.6.0-rc1" < "v4.6.0"`) and nightlies are compared by date (e.g., `"nightly-2024-01-10" < "nightly-2014-10-01"`). All other toolchain types and mixtures are incompatible. If there is not a single newest toolchain, Lake will print a warning and continue updating without changing the toolchain. If Lake does find a new toolchain, Lake updates the workspace's `lean-toolchain` file accordingly and restarts the update process on the new Lake. If Elan is detected, it will spawn the new Lake process via `elan run` with the same arguments Lake was initially run with. If Elan is missing, it will prompt the user to restart Lake manually and exit with a special error code (4). ### Other changes To implement this new logic, various other refactors were needed. Here are some key highlights: * Logs emitted during package and workspace loading are now eagerly printed. * The Elan executable used by Lake is now configurable by the `ELAN` environment variable. * The `--lean` CLI option was removed. Use the `LEAN` environment variable instead. * `Package.deps` / `Package.opaqueDeps` have been removed. Use `findPackage?` with a dependency's name instead. * The dependency resolver now uses a pure breadth-first traversal to resolve dependencies. It also resolves dependencies in reverse order, which is done for consistency with targets. Latter targets shadow earlier ones and latter dependencies take precedence over earlier ones. **These changes mean the order of dependencies in a Lake manifest will change after the first `lake update` on this version of Lake.**
When downloading a project using the VSCode extension, if that project is downstream of Mathlib there is a very long wait with no visual feedback or explanation of what is happening, while
lake
is cloning all of Mathlib.This corresponds to the following terminal output:
Even though I know this is an issue, the cancel button or ctrl-c is very tempting because it feels like something is wrong.
@tydeu, my suggestion here is to hard-code a check for Mathlib (yes, I know you don't like the idea :-) and before cloning Mathlib print a "info: cloning Mathlib, depending on your connection this may take some time".
There needs to be something to tell the user something is happening.
An alternative solution would be to investigate doing a shallow clone of Mathlib, but I'm not sure how viable that is.
See zulip discussion.
The text was updated successfully, but these errors were encountered: