Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Fix temp file bug #81

wants to merge 1 commit into from

Conversation

pcrockett
Copy link
Contributor

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.

Removed temp file altogether
@pcrockett
Copy link
Contributor Author

Oh darn you beat me to it :)

@xonixx
Copy link
Owner

xonixx commented Nov 21, 2021

Interesting idea, but probably won't work. In past I spent long time trying to find a way to not rely on temp files.
I think the main idea why I implemented it like this is to support the Makesurefile like

A=Hello
@define B="$A world"
@goal default
  echo $B

The trick with temp file allows to capture in them the "calculated" values of @define-d vars.
The additional constraint I chose to implement is to allow running prelude code only once (for efficiency, since it can have heavy initialization code, like reading files, etc.). This prevents the naive idea of simply prepending the goal bodies with the whole prelude.

Things to check (for me):

  1. Do we have proper test for this specific case with defines? Add if no.
  2. Document these details in developer notes doc.

Upd. And apparently the above snippet doesn't work. One more bug found.

@pcrockett
Copy link
Contributor Author

pcrockett commented Nov 21, 2021 via email

@xonixx
Copy link
Owner

xonixx commented Nov 21, 2021

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 DefinesCode won't capture A initialization.

@pcrockett
Copy link
Contributor Author

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:

pcrockett@4265f22

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.

@xonixx
Copy link
Owner

xonixx commented Nov 22, 2021

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.
Also it opens the possiblity to be abused or misused. What if users start writing huge codes in prelude, what implications will be?
Besides, why allow some arbitrary logic in prelude if this logically can be just anoter @goal initialized and any other goal can depend on it if need be.
Also the current operational behavior of @define-s is vague, such as even I, the author, am unsure how it really works.

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 :-)

@pcrockett
Copy link
Contributor Author

pcrockett commented Nov 23, 2021 via email

@xonixx xonixx self-requested a review November 23, 2021 12:12
@xonixx
Copy link
Owner

xonixx commented Dec 8, 2021

This is actually implemented in context of #84 and will be released soon.
Therefore closing this PR. @pcrockett thanks for your ideas!

@xonixx xonixx closed this Dec 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants