These ideas are in the direction of dealing with some of the issues encountered when developing large modular packages. Currently (I agree) that the flexibility of the module system of Julia has some trade-offs relative to more rigid models like Python’s.
Disclaimer: I have already mentioned that these ideas may not even be worth taken seriously. I am just winding up my imagination and I have no idea which would be the implementation difficulties and consequences. Yet, neither of the ideas seem to be breaking changes, at first sight.
The idea would be able to have one package, lets say
MyBigPackage registered in the general registry. But this package would be able to contain (parent?) other packages (
MySmallPackage2…), which would also have individual
uuids. The big package would be installed with
] add MyBigPackage, installing all small packages as dependencies, but each small package could also be installed independently with:
] add MyBigPackage.MySmallPackage1 and used with
using MyBigPackage.MySmallPackage1 even if
MyBigPackage is not installed.
Why: a) One would be able to develop
MyBigPackage with a modularity that would have all the advantages of the dependency system and modularity of regular dependencies. No more “includes” if one does not want to. b) The small packages would be available. c) This could alleviate the “name shortage” of packages. I would be able to have my
MyBigPackage.GramSchmidt package which would be potentially be available as a dependency to any other package (particularly other of my packages), without reserving the
Project.toml file could contain the list of the child packages.
I see some potential advantages in terms of debbuging and code organization if I could define a module that would be
Pluto like in those senses. Meaning:
@pluto_like module A f(x::T) = 1 struct T x end end
no code order (this is bad style, but still useful many times). But most importantly:
@pluto_like module A f(x::Int) = 1 f(x::Int) = 2 end
This would throw an error (multiple definitions, as in a Pluto notebook). Since Pluto already interprets the code like that, maybe that macro is easier than I thought.