You are right about env-vars and as I've noted, there might be security
concerns. The main goal here was to represent an idea for the source of the
import. It can be the module descriptor of vgo.
And the first idea is about having packages that does not harm the
environment (like by importing reflect or executing external commands), and
seems to be a feasible goal.
On Thursday, February 22, 2018 at 11:31:35 AM UTC+3:30, Axel Wagner wrote:
>> I'm looking forward to see this in official releases too!
>> Also I would like to:
>> - Have a mechanism for safe dependency packages (as in Safe-Tcl
>> <https://en.wikipedia.org/wiki/Tcl#Safe-Tcl> - this implies it would be
>> possible to have meta-data other than versions for packages, too).
>> - This one looks like a minor change in import syntax and might bring in
>> some security concerns: being able to use env-vars in imports: import
> Please don't. This is the antithesis to what vgo is trying to do. vgo
> tries very hard to marry reproducible builds with simplicity. Having
> environment variables determine what gets built destroys that completely.
> The occasional edge-case that might benefit from this should write their
> own tool which generates an appropriate package.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.