#getting "main modules"

1 messages · Page 1 of 1 (latest)

open skiff
#

@neon basin making sure I do this cleanly... Since I'll be calling this from core, I should:

  1. add the helper method to engine.daggerClient

then 2) add a method to core.Server interface so that I can access it from core?

neon basin
open skiff
#

OK cool, since there is already engine.Server. NonModuleParentClientMetadata(), I will add engine.Server.NonModuleParentClientModules()

#

and I will start using "main client" as a nickname for NMPC 🙂 shorter

#

(in my comments)

open skiff
#

@neon basin sorry to pester you with this, I implemented it correctly I think (pretty small amount of code) but I consistently get only the core module, and nothing else

#

I tried variations like cd foo; dagger; dagger -m foo, doesn't seem to make a different

neon basin
#

Might be easier to debug if you send out the code as a draft

open skiff
#

Ah... So maybe I'm calling this too early 😭

neon basin
open skiff
#

Because I'm doing it from ModuleSource.asModule

neon basin
open skiff
#

😭

#

I've been moving around looking for the best place to hook into. Previously I was in engine.Server.ServeModule

#

Module.asModule seemed reasonable, so that every Module has its local defaults already applied, to be inspected at will etc

#

But adding the concept of "main module" maybe throws a wrench in that

#

Maybe I could change my approach, and actually look for .env in the module's context directory in this case. That way I never have to check for "main module" at all

neon basin
#

Yeah I guess going back to your actual goal, arguably the simplest thing would just be to add an argument to the moduleSource/module API for controlling how the defaults are loaded. So then the caller (e.g. CLI) can just explicitly tell the server what behavior to use

#

That does pollute the API a bit arguably, but may not be end of world

open skiff
#

eg. when loading module mymodule:

  • Findup .env in host looking for FOO_xxx=yyy
  • Findup .env in module context looking for xxx=yyy
#

In the case where I'm loading a local module, and the .env is inside that module's git repo (by far the most common case), then the result will be the same (ie it will be the same .env)

#

When loading a remote module, then it will look for .env in that git repo, which most of the time won't be there. But, it does happen that module devs want to check in their .env ( eg @hoary tartan 's team actually does, they make sure they are safe to check in) so it's not a problem per se

#

Lastly, when loading a local module, if the .env is outside of the module git repo, it would be ignored for xxx=yyy -> which is kind of a good idea actually.

open skiff
#

IT WORKED party_blob