caxa icon indicating copy to clipboard operation
caxa copied to clipboard

Published 20 hours ago • verified publisher icon leafac

fix: use user cache directory instead of tmp

Open maxb2 opened this issue 2 years ago • 4 comments

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

Fixes #37. Related to #20.

maxb2 avatar Aug 11 '22 00:08 maxb2

@leafac any thoughts?

maxb2 avatar Aug 27 '22 14:08 maxb2

@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?

leafac avatar Aug 27 '22 15:08 leafac

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 avatar Aug 27 '22 19:08 maxb2

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 avatar Aug 30 '22 03:08 maxb2

I updated this to work on 3.0.1

maxb2 avatar Oct 20 '22 00:10 maxb2

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

matheussampaio avatar Jul 13 '23 21:07 matheussampaio

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

maxb2 avatar Jul 14 '23 03:07 maxb2

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...

unphased avatar Sep 27 '23 01:09 unphased

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.

leafac avatar Nov 21 '23 14:11 leafac