search

leafac / caxa

📦 Package Node.js applications into executable binaries 📦
https://npm.im/caxa
697 stars 33 forks source link

fix: use user cache directory instead of tmp #60

Closed maxb2 closed 10 months ago

maxb2 commented 2 years ago

This changes the extraction directory to the user cache using os.UserCacheDir().

Fixes #37. Related to #20.

maxb2 commented 2 years ago

@leafac any thoughts?

leafac commented 2 years ago

@maxb2: Yes, I have some thoughts! 😃

First, thanks for the contribution! It’s great to hear from you again.

Second, some questions:

  1. Do you think that the same behavior can be applied to the other kind of stub (the shell script one).
  2. Do you think we should change the TypeScript part of the application (the one that uses the stub and packages the program) in any way? Perhaps packaging is a one-off thing that can be done in the temporary directory. But perhaps it should be done in the cache directory as well. Thoughts?
maxb2 commented 2 years ago

Happy to contribute! :smile:

  1. I didn't know that existed. I'll change the behavior there as well.
  2. I think it's better that packaging is done in a temporary directory since it's a one-off thing. AFAIK, there is not an automated mechanism to clear the user cache directory.
maxb2 commented 2 years ago

I changed the shell stub to use the cache directories in the same way that the go function does. It's ready to merge :smile:

maxb2 commented 1 year ago

I updated this to work on 3.0.1

matheussampaio commented 1 year ago

Is there anything blocking this PR? I'm facing a lot of issues that may be resolved by this fix.

maxb2 commented 1 year ago

AFAIK, there is nothing blocking it. The original author has been missing from this project for a while though.

unphased commented 11 months ago

A slight tangent, but related to testing of this and related issues around failure to launch due to extraction woes. How do y'all test for windows releases? I noticed the exe I built from my last windows install (which has node.js installed) fails to execute properly on a new machine with freshly installed windows. Since I already need a windows setup to build a caxa self-extracting executable, and now I can't be certain that running it is an adequate test, it appears I need to have a windows VM or second windows machine on hand in order to do tests, which is not ideal...

leafac commented 10 months ago

Hi @maxb2, @matheussampaio, @unphased,

I’ve been thinking about the broad strategy employed by caxa and concluded that there is a better way to solve the problem. It sidesteps the whole issue of temporary directories, cache directories, and so forth.

It’s a different enough approach that I think it deserves a new name, and it’s part of a bigger toolset that I’m building, which I call Radically Straightforward · Package.

I’m deprecating caxa and archiving this repository. I invite you to continue the conversation in Radically Straightforward’s issues.

The original author has been missing from this project for a while though.

Yeah, I’ve been using caxa all along, but I was thinking of a more principled solution to the issues that I identified in caxa (including the one in this pull request), so I haven’t been merging pull requests. I’m happy that Radically Straightforward · Package is out as the new generation of caxa 🤗

How do y'all test for windows releases?

As far as I can tell the approach used by Radically Straightforward · Package should be more solid, because it doesn’t deal with self-extracting executables. It should be the case that you test your application on Windows, package it, and distribute it with confidence that the packaging didn’t introduce issues. Please give it a try and report back.

Best.