Why prefix environment variables?

[tpluscode]

Why does hurl expect environment variables to be prefixed with HURL?

This is quite annoying because everywhere else variable names are taken at face value. If I have a variable ENDPOINT that will be how I will define it and use in code

Hurl on the other hand wants them prefixed, which leads to duplication and special treatment when I want to share some settings between requests and other processes

[jcamiel]

Hi,

The why is more a convention that we try to respect regarding env variables.
Various CLI tool (venerable and modern) uses this kind of convention:

curl:
CURL_SSL_BACKEND
CURL_GETHOSTNAME
CURL_FORCETIME
CURL_ENTROPY
CURL_TRACE

grep:
GREP_COLOR
GREP_COLORS

Java:
JAVA_TOOL_OPTIONS
JAVA_HOME

More modern : brew (macos)
HOMEBREW_ADDITIONAL_GOOGLE_ANALYTICS_ID
HOMEBREW_API_DOMAIN
HOMEBREW_ARTIFACT_DOMAIN
etc...

That said, I can't say I know "everywhere else" 😅 and it's always interesting to see how other adress the same problem. Do you have example of such features in other CLI tools (just for comparison)?

Note: just to precise the actual Hurl usage, define such a variable export HURL_endpoint=https://foo.com is defining a variable endpoint in the Hurl file:

GET {{endpoint}}
HTTP 200

doc: https://hurl.dev/docs/templates.html#injecting-variables

[tpluscode]

I think we're talking slightly different purpose here.

For example, any CURL_* variables would be used for any curl command. That is to apply certain configuration to every usage or the tool.

I find the variables used in templates a different use case where you configure specific set of *.hurl request files with inputs specific to a project, etc.

To make an analogy, I think of template variables more like function parameters. If I give them specific names in the template, I would not like to differentiate in how I address them depending on how a function (request) is called

[tpluscode]

Circling back to hurl, yes, I agree that anything which is hurl's "own" option could be also sourced from the ENV. Such as --compressed could also be replaced globally with HURL_compressed=true

Variables on the other hand are not hurl options but user-defined request options. That is the difference I see

[tpluscode]

Any thoughts on that?

[jcamiel]

Hi @tpluscode , a quite late response to your suggestion, we're indedd going to add support for this kind of configuration (HURL_INSECURE for --insecure) see #3901 (comment)

[fabricereix]

At any time, we can also easily log/check which variables is being in Hurl.

$ export HURL_greeting=hello
$ echo |  hurl --verbose --variable toto=tata
* Options:
*     fail fast: true
*     follow redirect: false
*     insecure: false
*     max redirect: 50
*     retry: false
*     retry max count: 10
* Variables:
*     toto: tata
*     greeting: hello
warning: No entry have been executed