Typically you want to upgrade pkgx so either:
brew upgrade pkgx; orcurl -LSsf pkgx.sh | sh
{% hint style='info' %}
Yes. Our installer upgrades pkgx too.
{% endhint %}
Unless otherwise instructed, pkgx executes the latest version of packages that
are downloaded. The first time you run a package the latest version will be
downloaded, but after that updates will only be fetched if requested or required
by other packages.
For us neophiliacs we have written a [mash] script to upgrade your pkgx
packages:
pkgx mash upgradeUse pkgm.
A package is:
- A plain tarball containing a single project for a single platform and architecture compiled from that project’s sources
- A bundle of metadata (
package.yml) from the [pantry]
Relative to some other packaging systems:
- No scripts are executed post “install”
- Packages must work from any location (we say our pkgs are “relocatable“)
Sorry about that. Open a ticket asking for it and we’ll build it.
The commonly used @ syntax would evaluate to v20.1.x (@20.1.3).
To provide more control we support the
full semantic version range syntax. So for the
given example we would use the caret (^):
$ pkgx node^20.1.3 --version
v20.1.5Which will match node v20.1.3 up to but not including v21.
+pkg syntax is a way to include additional pkgs in your environment. Typing
pkgx +deno dumps the environment to the terminal, if you add additional
commands then those commands are invoked in that environment.
We have created a [mash] script to list everything pkgx has downloaded:
pkgx mash lsAll packages are encapsulated in individual, versioned folders in ~/.pkgx just
like brew so you can just browse them with a file browser.
Open source is ever moving and somebody needs to keep up with it. You may need to contribute to the pantry.
Everything goes in ~/.pkgx. eg. Deno v1.2.3 is an independent POSIX prefix at
~/.pkgx/deno.land/v1.2.3, thus the deno executable is at
~/.pkgx/deno.land/v1.2.3/bin/deno.
We also create symlinks for majors, minors and latest:
$ cd ~/.pkgx/deno.land
$ ls -la
v* -> v1.2.3
v1 -> v1.2.3
v1.2 -> v1.2.3Open source is vast and unregulated, thus we use fully-qualified naming scheme to ensure pkgs can be disambiguated.
Yes! Our pkgs are relocatable.
We would love to support all platforms. All that is holding is back from new platforms is expertise. Will you help? Let’s talk.
You need to add to the pantry.
{% hint style="info" %}
Eventually we will support describing how to build or
obtain distributables for your package via your repo so you can just add a
pkgx.yaml and users can use pkgx to use your package automatically.
{% endhint %}
pkgx your-package --argsYou can also recommend our shell one-liner if you like:
sh <(curl https://pkgx.sh) your-package --argsThis is neat because pkgx is not installed and it runs your package from a
temporary location making this a very low friction way to try out your package.
Finally, you can have them try your package out via our Docker image:
docker run pkgxdev/pkgx your-package --argssudo rm /usr/local/bin/pkg[xm]
rm -rf ~/.pkgxThen there are a couple platform specific cache/data directories:
rm -rf ~/Library/Caches/pkgx
rm -rf ~/Library/Application\ Support/pkgxrm -rf "${XDG_CACHE_HOME:-$HOME/.cache}/pkgx"
rm -rf "${XDG_DATA_HOME:-$HOME/.local/share}"/pkgx{% hint style="warning" %}
Though not a problem unique to pkgx you should note that tools run with pkgx
may have polluted your system during use. Check directories like:
~/.local~/.gem~/.npm~/.node- etc.
{% endhint %}
The rules for @ are complex, but more human. We convert them to the following
semver syntax:
@3→^3@3.1→~3.1@3.1.2→>=3.1.2<3.1.3@3.1.2.3→>=3.1.2.3<3.1.3.4- etc.
Packages are downloaded to $PKGX_DIR if set. If not set:
- macOS
~/Library/Packagesif the directory exists~/.pkgxotherwise
- *nix
~/.pkgxif the directory exists${XDG_DATA_HOME:-$HOME/.local/share}/pkgxotherwise
Some cache data is stored:
~/Library/Caches/pkgxon Mac${XDG_CACHE_HOME:-$HOME/.cache}/pkgxon *nix%LOCALAPPDATA%/pkgxon Windows
We error with a method to disambiguation, eg:
$ yarn
× multiple projects provide: yarn
│ pls be more specific:
│
│ pkgx +classic.yarnpkg.com --internal.use +yarn
│ pkgx +yarnpkg.com --internal.use +yarn
│
╰─➤ https://docs.pkgx.sh/help/ambiguous-pkgspecman foo won’t work since pkgx pkgs are not “installed”. Thus you have to first
create an environment that contains that package before invoking man:
pkgx +foo man fooThis uses pkgx’s man tool. To use the system man:
pkgx +foo -- man foo