-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix temp file bug #81
Conversation
Removed temp file altogether
Oh darn you beat me to it :) |
Interesting idea, but probably won't work. In past I spent long time trying to find a way to not rely on temp files.
The trick with temp file allows to capture in them the "calculated" values of Things to check (for me):
Upd. And apparently the above snippet doesn't work. One more bug found. |
You're right, and on my first attempt I didn't think about that. However there were tests! https://github.com/xonixx/makesure/blob/main/tests/18_vars_priority.sh
My second attempt is what you see here. I also believe we are still only executing the prelude once.
Think of it this way: Instead of appending @define lines to a file and dot-sourcing the file for every goal, we are now saving the lines in memory and prepending them to every goal. So I actually think this may result in a performance improvement, because we're not forcing the shell to open and read the same file multiple times.
(Assuming I correctly understand how it all works... A large assumption indeed.)
|
Absolutely agree on performance aspect and wish to get rid of temp files. However the test https://github.com/xonixx/makesure/blob/main/tests/18_vars_priority.sh doesn't capture the case in snippet above. So your solution will work on case like @define A="A"
@define B="B $A" but won't with A="$(curl some-url)" # we don't want to expose A to goals
@define B="A=$A" # but we do want to expose B Because in your case |
Ah ok I understand. It looks like that use case has never been supported though. To verify, I created a failing test on the main branch here: So that does look like a separate issue. Do you think we should put this in its own separate issue? I have some thoughts about it, but we're starting to get off-topic for this PR. |
Yeah, it's funny, but this is how I designed initially and how I believed it really works. Now this whole discussion made me to strongly reconsider the real necessity of the notion of prelude (the script that unconditionally runs before all goals). It appears that if I myself didn't need to use it to the whole power, maybe it's useless after all. This makes me think that we can just drop this feature and only allow plain static defines like @define A 'a value'
@define B 'some othe value' # can not reference A I need some time to analyze all pros and cons now. Definitelly this is in spirit of Worse is better which I strongly believe in. This is definitelly a breaking change, but I doubt it hurts anyone, since the user base is still very small :-) |
I think I agree.
I will say I often do things like this:
@define A_FILE_NAME="filename"
@define A_FILE_PATH="path/to/${A_FILE_NAME}"
However I have never done anything like this before:
A_FILE_NAME="filename"
@define A_FILE_PATH="path/to/${A_FILE_NAME}"
Which makes me think that yes, the prelude is unnecessary. @goal, @lib, and @define have all the functionality you need, and encourage better organization.
|
This is actually implemented in context of #84 and will be released soon. |
I had fun with the previous PR and thought maybe I could try my hand at fixing the bug you found as well. Removed the temp file altogether.