Thanks Axel, 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: > > On Thu, Feb 22, 2018 at 7:10 AM dc0d <kaveh.sh...@gmail.com <javascript:>> > 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 >> "$MY_OTHER_PKG". >> > > 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 "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
