Could we make first-class support for packages that are "just files" and not repositories?

General Usage
,
3

Thanks @Tamas_Papp, but I’m confused. For LocalRegistry, it seems like packages still need to be individual git repos, no? I might need to clarify my post a bit:

The individual repos thing doesn’t work for me, or for other people that I talk to in engineering. I need to have all of my code related to the aircraft simulation in one big repo; it’s in there with a bunch of other code (Julia is only a small part of this project). The way packages are brought in in general (e.g., any module anywhere can using CommonTypes, and they all get the same types) is very attractive, but I’m going to need the CommonTypes package to just be some code located in some subdirectory of my repo, not its own git repo.

]dev path/to/CommonTypes works well, but only for one level. Once you have multiple ]dev’d packages, you end up having to resolve dependence manually, as mentioned in "Unsatisfiable requirements" when local packages use local packages (fixed in v1.4).

Maybe what’s not clear in my original post is that by “local, unregistered package” I mean just a subdirectory that’s structured like a package in my overall repo:

/.git
/analysis # All the other code in the repo...
/drivers
/flight
/sim # The Julia part
  /Aerodynamics # A local package
    /src
    Project.toml # Depend on CommonTypes
    Manifest.toml
  /CommandTypes # Another local package
    /src
    Project.toml
    Manifest.toml
  /HugeSim
    /src
    Project.toml # Directly depends on Aerodynamics, but not on CommonTypes
    Manifest.toml
  /SmallSim
  /StudyOfAerodynamics # etc.
  ...

As far as I can tell, using these local paths as packages doesn’t really work, because ]dev LocalPackage doesn’t resolve dependencies, so, for this example, HugeSim would also need to ]dev ../CommonTypes prior to including the things that depend on CommonTypes, like ]dev ../Aerodynamics. So, each project moving up has to explicitly write out all of the local dependencies for anything it uses, and for anything that those use, etc.

If local dependency resolution worked for ]dev, then this whole thing would work perfectly as far as I can tell. That’s probably the most important thing to highlight.

For what it’s worth, I also think that using local packages would be an easy way for folks (at least people like me) to learn about creating a program structure that uses multiple packages. It just helps minimize the boilerplate.

Ok, I hope that clears up my intent rather than just drowning everything in detail. Please let me know if this makes sense!

2 Likes