Like I said in the above thread, I want to change the current environment variables for the program, not for a subprocess

@thiagokokada https://gist.github.com/mikeananev/c87c1596aed50b7bb095a816f6921737 you can read env vars for the current process (see line 14) and then modify them as usual map.

I may have understand wrong, but in this case I really need to export the environment variables again

I can of course inject then in every shell call and every usage in my Clojure program, but this get old really quickly

awesome!

@UGNFWPPGF I started with your work as inspiration, but i couldn’t figure out how to do nested completions. I’m not sure if the AWS approach is better or not, but it works

https://github.com/jeroenvandijk/matryoshka/blob/9f70e63418b7b9ee7a58255d83a392da4b7f35de/matryoshka#L83 This is not a "doesn't work yet" problem, but a problem that aliases are only valid in the next top level s-expression. You should use resolve to resolve a fully qualified symbol, if you are in the same expression.

Clojure 1.10.1
user=> (defn foo [] (require '[clojure.set :as set]) (set/union #{1 2 3} #{4 5 6}))
Syntax error compiling at (REPL:1:47).
No such namespace: set

Yeah indeed. I guess I have to have a better look at what you did in bb tasks. This was a quick “addon” for now (i should have left it out)

bb tasks pushes all the :requires to the top level

@U0FT7SRLP would your solution work for both bash / zsh? it would be very nice :)

I’m using zsh, not sure about bash, but I’m guessing if we try we could even make it work for Windows 🙂 It uses the same approach as the AWS tool https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-completion.html#cli-command-completion-linux

🤯

The output is slightly different from what @UGNFWPPGF did. Maybe the underlying framework is different

I don’t know if this is the way for bash, but in my (basic) bash shell it doesn’t work:

bash-3.2$ autoload bashcompinit && bashcompinit
bash: autoload: command not found
bash-3.2$ autoload -Uz compinit && compinit
bash: autoload: command not found
bash-3.2$ compinit
bash: compinit: command not found
bash-3.2$ export PATH=".:$PATH"
bash-3.2$

not out of the box at least 😅

@U0FT7SRLP really cool!

i'll have to dig into the implementation later today

the other thing that keeps coming to mind is wanting to support all of bb's cli opts, not just tasks

@U04V15CAJ I’ve fixed the :deps and :requires “feature”. This works now https://github.com/jeroenvandijk/matryoshka/blob/main/tasks/custom.edn

nice! is this about completion or also about building an alternative task runner?

I don’t know yet. I am looking for something that I can use or all my projects. The autocompletion makes this actually feasible. You start with a category and the suggestions help you navigate

I was thinking of wrapping these commands https://github.com/practicalli/clojure-deps-edn so that I can use them everywhere without having to do constant lookups

what are you currently missing from bb.edn's task runner?

I’m not sure if I’m missing something other than the global part

how does your task runner implement "global" ness?

good question. Not in some particular way, but the difference with babashka tasks is that all the tasks are isolated and it has a tree structure so it should stay fast

I’m not saying this could not be part of babashka tasks and that this is better (i just started working on it today so it’s nothing really). I don’t know yet where this will end. When I have a structure I like I’ll try to see what the main differences are

fast in what sense?

If I have a global library of tasks this could easily become really big. So code loading would be an issue if you are not careful. If you try the aws cli you feel the difference 🙂

But i think it’s a bit premature to talk about my “benefits”. I’m not actually using it for something

well, it's good to take future use case into account without locking down the design to exclude that possibility right now, that's why I am asking

Especially the autocompletion needs to stay fast for a nice experience

The #include is lazy loading here https://github.com/jeroenvandijk/matryoshka/blob/main/tasks.edn#L1

cool :)

So you don’t get hit by a huge startup penalty when you add many libraries. It’s only about the nesting. So a nesting of 4 would mean having to load 4 of these files

instead of something to the power of 4

I think these things can also be implemented using normal keywords instead of reader tags btw

right now a pretty large bb.edn still loads in 1ms

it's first parsed as EDN only and only the task that is executed is actually re-parsed as code

ah yeah so i’m guessing it’s a bit premature

i was also thinking what if you could add a module

i was thinking you could have an aws module and it would look like this file

that was my fantasy at least 😅 Not sure what parts are actually required for this to work

I’m curious how you would use keywords instead of the reader tags btw

(I stole the #include idea from https://github.com/juxt/aero btw. That one is not lazy though)

{:cmds {aws {:cmds "tasks/aws.edn"}}}

haha hmmm no that would be too simple 😛

fair enough, that would be better

yeah, I know that lib. personally I would like to avoid reader tags a little bit, but maybe my feeling isn't justified on good reasons

no i think you are right, probably better to keep it simple

Note sure if it is related, but I noticed that babashka.deps/add-deps doesn’t complain when I give it rubbish

what kind of rubbish

it just passes stuff through to tools.deps basically

and tools.deps picks up on the local deps.edn

I didn't add the '{:deps ...}' wrapping and I was wondering why my require wasn't working. So not really rubbish, but it was invalid config

+1 here. I ran into the above described situation as well. I can confirm it can give unexpected errors and slower load time

in which case?

slower as in what, can you be more specific? btw, I am working on a fix as we speak

it should be fixed now. try one of the binaries from #babashka-circleci-builds

Cool 🙂

The case where it was giving me unexpected results was when I had my custom bb tasks runner script and giving it empty {:deps {} } . So I wasn’t expecting anything, however the deps.edn in that directory had an error, so the whole call failed. But the script I was trying to run was a hello world (without deps), so it was confusing at first

Normally this hello world would be quick, but due to the (failing) deps it was slower

i’ll try the new binary!

I'll add another check for an empty deps map, since it doesn't have to call out to tools.deps in that case

so far everything works. Calling tools.deps with an empty map adds 10ms. Not major

cool