| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Instead of having Lua registries instantiate package instances
themselves we now do it in the installer of Lua registry sources.
This aligns the behaviour of the Lua registry protocol with the other
registry protocols.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the following public APIs:
**(_breaking_) Events on the `Package` class**
The `uninstall:success` event on the `Package` class now receives an `InstallReceipt` as argument, instead of an
`InstallHandle`. This receipt is an in-memory representation of what was uninstalled. There's also a new
`uninstall:failed` event for situations where uninstallation for some
reason fails. Note: this also applies to the registry events (i.e.
`package:uninstall:success` and `package:uninstall:failed`).
---
**(_breaking_) `Package:uninstall()` is now asynchronous and receives two new arguments, similarly to `Package:install()`**
While package uninstallations remain synchronous under the hood, the public API has been changed from synchronous ->
asynchronous. Users of this method are recommended to provide a callback in situations where code needs to execute after
uninstallation fully completes.
---
**(_breaking_) `Package:get_install_path()` has been removed.
---
**`Package:install()` now takes an optional callback**
This callback allows consumers to be informed whether installation was successful or not without having to go through a
different, low-level, API. See below for a comparison between the old and new APIs:
```lua
-- before
local handle = pkg:install()
handle:once("closed", function ()
-- ...
end)
-- after
pkg:install({}, function (success, result)
-- ...
end)
```
|
| |
|
|
| |
Closes #1156.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#1523)
This contains the following changes:
1) `Package:install()` now accepts a second, optional, callback argument which is called when installation finishes
(successfully or not).
2) Adds a `Package:is_installing()` method.
This contains the following breaking changes:
1) `Package:install()` will now error when called while an installation is already ongoing. Use the new
`Package:is_installing()` method to check whether an installation is already running.
This also refactors large portions of the tests by removing test globals, removing async_test, and adding the
`mason-test` Lua module instead. Test helpers via globals are problematic to work with due to not being detected through
tools like the Lua language server without additional configuration. This has been replaced with a Lua module
`mason-test`. `async_test` has also been removed in favour of explicitly making use of the `mason-core.async` API. These
changes stands for a significant portion of the diff.
|
| |
|
|
|
|
|
|
| |
Renaming the file will move it from its original installation directory. While reaching into package installation
directories is unsupported and not recommended, it seems to be done pretty broadly. In order to avoid unnecessarily
breaking people's configs we copy the file instead, for now. (tip: use the stable locations inside $MASON/share
$MASON/opt $MASON/bin, if a package is missing a link please open an issue/PR).
This will be reversed back to use uv_fs_rename() in 1.x.x.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) FAT (FAT32, exFAT, etc.) file systems doesn't support symlinks.
2) You need administrator access in order to create symlinks.
This was working for me locally because I'm running a NTFS fs with
"Developer Mode" enabled in Windows 10, which bypasses administrator
requirement for mklink.
Instead we uv_fs_rename() links. This should effectively be the same,
but will require special handling down the road if/when for example
multiple package versions can be installed at the same time. When
unlinking a package the renamed files should me moved back into the
package installation directory, instead of simply being unlinked (i.e.
removed).
Closes #1251.
|
| |
|
|
|
| |
* chore(workflows): update dependencies
* style: enforce import order
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* feat(installer): add share links
Adds the ability to symlink share files to ~/.local/share/nvim/mason/share (default location). This is currently not
used by any packages but will be soon (e.g. linking .jar files to a canonical location on the fs).
This also includes the following changes:
- fix(windows): correctly unlink executables
Prior to this change, executables on Windows would not be removed when uninstalling a package.
- refactor(installer): use Result interfaces
The motivation behind this is to move away from exceptions and pcalls to leverage the Result interface.
This allows for better error messaging during installation, as well as improved composability of actions that may
or may not fail.
- refactor(bin): use absolute paths in exec wrapper scripts
While relative paths are preferred and will end up returning in the future, they i) cannot be guaranteed for all
packages, and ii) is somewhat complicated to produce due to lack of std APIs.
Moving the entire Mason installation directory was never officially supported anyway.
- feat(installer): add "force" flag
When this flag is true, any existing executables or share files will be overridden if they exist (i.e. mangle another
package installation).
* refactor(result): always return Result objects in Result.try
The rationale here used to be that exceptions in Result.try() blocks were treated truly as exceptions that should
interrupt code execution per Lua's traditional error handling semantics. However, Lua code is somewhat prone to raise
exceptions when you don't expect it to (especially when interacting with loosely documented external APIs). Combine this
with the fact that code that invokes Result.try() blocks generally doesn't `pcall` and only relies on the Result API to
handle errors, you end up with code that only gracefully handles one class of errors (the well-known ones).
* test(terminator): sleep in tests to avoid race condition
I've no idea why this doesn't pass in CI, works just fine locally.
|
| |
|
|
|
| |
Mac systems are generally referred to as the Darwin OS. For all intents
and purposes, "mac" and "darwin" can be used interchangeably (although
darwin will be preferred going forward).
|
| | |
|
|
|
* feat(installer): don't write exec wrappers for targets that don't exist
Just a precaution to avoid writing broken executables.
* test(installer): add spec files for context and linker
|