On Tuesday, 28 February 2023 at 16:15:44 UTC, Bradley Chatha wrote:
> Unlikely: In your example they can still use imports by doing something like `mixin("impor"~"t std.file;");`

I'm a numpty, I didn't read your post carefully enough :D

On Tuesday, 28 February 2023 at 16:10:19 UTC, Steven Schveighoffer wrote:
> On 2/28/23 10:15 AM, Adam D Ruppe wrote:
>> On Tuesday, 28 February 2023 at 14:29:28 UTC, Mathias LANG wrote:
>>> Obviously such a change would not happen overnight, and would need broad support from the community. Opinions ?
>> 
>> Here's a wild idea: use the D language. Most the things dub.json defines are already available in D anyway.
>
> Is there a way to do this and prevent mischief? Like maybe:
>
> ```d
> module buildfile;
>
> import safe.modules.only;
>
> static immutable buildcode = import("build.d");
>
> shared static this() {
>    import dparser;
>    parseEnsuringNoImportsOrMixins(buildcode);
> }
>
> void build() {
>    mixin(buildcode);
> }
> ```
>
> -Steve

whats preventing some buildfile from including some malicious cmd line in dub?
if you want to restrict buildfiles, they become pretty useless for a lot of cases

On Tuesday, 28 February 2023 at 16:10:19 UTC, Steven Schveighoffer wrote:
> module buildfile;

This isn't what I'm talking about at all.

I don't want to run D to build, I want to *introspect* D for build info. You can read module names, dependencies (including platform-specific and configuration-specific ones) right out of D code. Author, description, license, etc., have standard ddoc sections in D code.

Other things dub.json define like flags could easily be a UDA on the module declaration and be pulled out pretty easily by compilers or even relatively basic parsers.

Even subconfigurations can... kinda be pulled out of D code by looking for version blocks though that's probably another thing I'd put on a UDA.

On Tue, Feb 28, 2023 at 04:32:42PM +0000, Adam D Ruppe via Digitalmars-d wrote:
> On Tuesday, 28 February 2023 at 16:10:19 UTC, Steven Schveighoffer wrote:
> > module buildfile;
> 
> This isn't what I'm talking about at all.
> 
> I don't want to run D to build, I want to *introspect* D for build info. You can read module names, dependencies (including platform-specific and configuration-specific ones) right out of D code. Author, description, license, etc., have standard ddoc sections in D code.
> 
> Other things dub.json define like flags could easily be a UDA on the module declaration and be pulled out pretty easily by compilers or even relatively basic parsers.
> 
> Even subconfigurations can... kinda be pulled out of D code by looking for version blocks though that's probably another thing I'd put on a UDA.

Hmm.  Now THIS is an awesome idea.  Instead of having a separate build description apart from the code, inspect the code itself to figure out how to build it.  With the help of UDAs and other such annotations to help things along.  This is definitely a direction worth exploring!


T

-- 
When you breathe, you inspire. When you don't, you expire. -- The Weekly Reader

On Tuesday, 28 February 2023 at 16:32:42 UTC, Adam D Ruppe wrote:
> On Tuesday, 28 February 2023 at 16:10:19 UTC, Steven Schveighoffer wrote:
>> module buildfile;
>
> This isn't what I'm talking about at all.
>
> I don't want to run D to build, I want to *introspect* D for build info. You can read module names, dependencies (including platform-specific and configuration-specific ones) right out of D code. Author, description, license, etc., have standard ddoc sections in D code.
>
> Other things dub.json define like flags could easily be a UDA on the module declaration and be pulled out pretty easily by compilers or even relatively basic parsers.
>
> Even subconfigurations can... kinda be pulled out of D code by looking for version blocks though that's probably another thing I'd put on a UDA.

Oh wow, that's definitely an interesting idea.

Have you written down a more refined version of these thoughts?