tbrand/neph

Command callback

Closed this issue · 10 comments

Hi,

Some job COULD requires external command to run, in order to prepare the environment (for example).

Is this a good idea to use callback / crystal custom code in order to customize some jobs ?

Regards,

Is this a good idea to use callback / crystal custom code in order to customize some jobs?

Crystal is a compiled language, so dynamic evaluation can't be done in runtime.

What do you mean under callback?

What do you mean under preparing the environment? Setting environment variables?

What do you mean under external command?

Crystal is a compiled language, so dynamic evaluation can't be done in runtime.

Sure.
However macro is an alternative to dynamic evaluation ;-)

What do you mean under callback?

Callback are some logic designed to run (for example after env -> clean).
It could also be to prepare the environment or set environment variables

It's like after_commit .... in ROR, http://guides.rubyonrails.org/active_record_callbacks.html

Macros are expanded in compile time.

I'm not familiar with web development, so the Rails example don't say too much for me.
Do you mean launching a Neph job from inside a command running in the shell?

Could you provide an example, how you would use callbacks in Neph?

Is preparation of the environment only variable setting in this case?

Environment variables can be set in the Neph config file.
Another solution is to capture the output of one job into an environment variable, and use this variable in another job.

Environment variables can be set in the Neph config file.

Could env be exported to each commands, or globally ?

I think setting environment variables for each command is unneeded. Environment variables could be set globally (the config part of the document), or for a particular job (but all commands in that job would have the same environment - if a command needs a different environment, it should be placed in a separate job). I want also implement recursive environment variable setting (the environment variables specified for a job will be set for all subjobs - avoid copy-paste).

in fact, I've tried global env in the-benchmarker/web-frameworks#138, but it seems that each jobs are not understanding env.
For example, I've set

env:
  KEMAL_ENV: production

but kemal still run on development (the mode in which kemal run is defined by the env var KEMAL_ENV)

I don't want to fix any bugs in this version, I am now working on the redesigned config file format, that is more flexible.

ok. I've found some fix for my use case

The new environment variable setting options will be included in the new config format.

👍