I think you're overcomplicating things. I write code. That code, across a few files, is a module, and that module has a config file, which specifies certain metadata, and optionally some dependencies. I get those dependencies as other modules, which are in some sort of tree, or maybe in some user-wide package store. I can bundle this together into bundles, which are how the code gets distributed to end users, who only need to have Rabbit installed, which then runs the bundle.
If I'm a developer, I have carrot, which is how I actually install those dependencies to put in the bundle
It gets those from various repository types, including bundles, which are just big directories of unorganized modules
It defaults to a central repository you, Ginger, run, but you can also install from other sources
what you've described is almost correct... except for one thing
the Rabbit interpreter cannot exist independently from carrot, except for within application bundles (okay technically it can but it's going to be a real pain in the ass to use)
because of a detail of carrot I may have not elaborated on until now: carrot manages, in addition to modules, installing copies of the Rabbit interpreter and launching Rabbit modules
If I install a bundle file from apt or dnf, it should be able to list Rabbit as a dependency, instead of carrot, which then is maintaining Rabbit in parallel to the system package manager
Like I'd assume you give the interpreter a path to either an individual script, or to a module config which would specify what to run and what dependencies it needs
@RydwolfPrograms you tell the interpreter two things: the module name and version to run and paths to the libraries to look for it in
I'm doing this because I am sick and tired of Python libraries being installed from twenty conflicting and often out-of-date sources, so I'm making it so there is one, and ONLY one, correct way to install Rabbit and its modules
Rabbit solves that by making sure that only valid and known libraries are being used; in fact, generally only two libraries are searched: the user one and the global one
Ginger, this is a solved problem. There are two valid approaches. Either all the dependencies get stored in one central user-wide store (just a directory full of modules), or you use a tree structure and store all of the dependencies of a module alongside it
if you're adding extras you are doing it wrong (unless it's for developing code, in which case it's fine to have your workspace as an additional library)
I'm the edge case person; I hate it when people make things like module paths set in stone because it means I often can't use their tools in the conditions I need to use them in
Example: Poetry doesn't handle extra Python module repos well, which is annoying because it means I can't use Piwheels with it
also, side note re. OS package managers: carrotdoes support installing modules via an OS package manager
also also: because carrot is itself a Rabbit module, it can also be installed through an OS package manager
to fix the issue of carrot needing a Rabbit interpreter to run itself, its OS package would probably include a bootstrap script that installs a bundled interpreter for carrot to run on; after that point carrot can install a newer version as needed
the same thing would be done in the "official" install shell script, just with a dash more interactivity
(and I say "official" here because the OS packages will be as official as any other; the script's just in case you don't have a package manager to use)
I was going to say that the type objects that your compiler uses don't need to be at all connected to the type objects that you use for runtime reflection
I still think you're doing it wrong, but I know even less about interpreters than I do about compilers so I can't really give you unsolicited advice there
@lyxal We've got ? and ?! already, they're called warnings and errors
@ATaco Discussions can have sides too. People can push a particular solution to a problem they're discussing. Arguments are just less open, more heated