question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Feature] Allow specifying alternative extraction / temporary directory

See original GitHub issue

The Readme file reads:

To Where Are the Packages Uncompressed at Runtime? It depends on the operating system. You may find the location on your system with: $ node -p "require(\"os\").tmpdir()" Look for a directory named caxa in there.

Temporary directories are, well, temporary, and may get deleted when the user logs out or reboots the machine, depending on system configuration. I’d like to avoid that, to avoid the occasional performance hit which would be bad UX for end users (and might be “mysterious” to them). My app has hundreds of megabytes in node_modules and the runtime extraction time is non trivial (in excess of 10 seconds in a fairly fast machine with a SSD disk, possibly 30+ seconds in a slow machine).

  • A flag of the caxa command line could allow specifying an alternative folder (other than "require(\"os\").tmpdir()"). Say, --extract-dir /usr/local/lib/myApp.
  • In addition, a {{PREFIX}} string could be replaced at runtime with the value of the PREFIX environment variable, with a default value specified as {{PREFIX=/default/prefix}}.

Examples:

$ caxa --extract-dir "C:\Program Files\myApp" ...
$ caxa --extract-dir "/opt/myApp" ...
$ caxa --extract-dir "{{PREFIX=/usr/local}}/lib/myApp" ...

In the last example above, at runtime, if the PREFIX environment variable was defined and set to '/usr', then the app would be extracted to /usr/lib/myApp. If the PREFIX environment variable was not defined, or if it was defined and set to /usr/local, then the app would be extracted to /usr/local/lib/myApp.

I appreciate that extracting to a folder like /usr/local would require superuser privileges / sudo. That’s OK.


Rationale I was thinking of using caxa as a sort of “installer” for my app. I would set the --command entrypoint to a short JavaScript module (part of the app) that would additionally create a symlink or file at, say, /usr/local/bin/myApp that would look like:

#!/usr/bin/env sh
/usr/local/lib/myApp/node_modules/.bin/node /usr/local/lib/myApp/bin/main.js

Or some variation of this. Then running myApp on a command prompt would execute /usr/local/bin/myApp, and in turn /usr/local/lib/myApp/node_modules/.bin/node .... One could even consider that caxa could provide a standard “installer mode” feature that would do just that, but this is probably for some other feature request. 😃

“If you just want caxa to extract / install the app, why not just use a traditional installer?” Well, that’s what I’m currently doing on Windows (NSIS) and macOS (pkgbuild), but I am currently considering the options on Linux and every option I came across had some drawbacks, for example:

  • .AppImage (squashfs) depends on fuse which in turn requires a Docker container to run in privileged mode.
  • apt install myApp à la Spotify requires setting up repository keys and is not available on some Linux distributions.
  • pkg has the complications listed in caxa’s Readme and the latest versions have some bugs related to fs promises and native node modules. I have used pkg for years but found myself spending a lot of time chasing bugs because of the modifications that pkg makes to Node.js.
  • Plain shell scripts tend to snowball into large files full of corner cases depending on whether curl or wget or bash or POSIX sh or apt or apk are available, “unless it’s Arch Linux or Fedora or”… And I’d rather code in JavaScript, like the rest of the app.
  • Snap and Flatpak depend on daemons / systemd / d-bus …

At which point I came across caxa and thought, “this might just do the trick!” Simple enough and universal enough, especially with the upcoming ARM support in issue #4. 😃

Issue Analytics

  • State:open
  • Created 2 years ago
  • Reactions:5
  • Comments:18 (9 by maintainers)

github_iconTop GitHub Comments

6reactions
TheBotlyNoobcommented, Sep 11, 2021

👍 Please Add This!

3reactions
dadiborncommented, Sep 23, 2021

I will join that party! Me too needs that option to change Temp dir to custom one, please add this option , thank you!

Read more comments on GitHub >

github_iconTop Results From Across the Web

using an alternate /tmp location with pyinstaller - Stack Overflow
Where to extract libraries and support files in onefile-mode. ... The script had the temporary location hardcoded so I made changes there.
Read more >
Specifying an alternative temporary directory for installation
If the default temporary directory is not accessible, you can specify an alternative temporary working directory to perform installation.
Read more >
tempfile — Generate temporary files and directories — Python ...
This module creates temporary files and directories. It works on all supported platforms. TemporaryFile , NamedTemporaryFile , TemporaryDirectory , and ...
Read more >
tempfile: Create Names for Temporary Files - Rdrr.io
The environment variables TMPDIR, TMP and TEMP are checked in turn and the first found which points to a writable directory is used:...
Read more >
Working With Files in Python
Traversing Directories and Processing Files; Making Temporary Files and ... Let's explore how the built-in Python function os.walk() can be used to do...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found