# Can a module in a package itself be a package?

**URL:** <https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474>\
**Category:** General Usage\
**Created:** [April 24, 2024, 7:59pm UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474 "2024-04-24T19:59:19Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![sadish-d](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sadish-d/32/48058_2.png) [@sadish-d](https://discourse.julialang.org/u/sadish-d)\
**Post date:** [April 24, 2024, 7:59pm UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/1 "2024-04-24T19:59:19Z")

</div>

I have a pacakge (PackageCore) that provides the main functionality of another (PackageFull). I’ve decided that I want to be able to develop and test these as independent packages. This is the structure I am currently using:

```julia
PackageFull
	src
		PackageFull.jl
	test
		runtests.jl
	Project.toml
	Manifest.toml
	PackageCore
		src
			PackageCore.jl
		test
			runtests.jl
		Project.toml
		Manifest.toml

```

When I develop PacakgeFull, I do `]dev "path/to/PackageFull"`. When I develop PacakgeCore, I do `]dev "path/top/PackageFull/PackageCore"`.

The important bit is: I don’t add/dev PackageCore as a package/dependency from PackageFull. Rather, in `PackageFull.jl` I just `include("../PackageCore/PackageCore.jl")`. In other words, for PackageFull, PackageCore is just a module defined within `module PackageFull ... end`, not a package.

Is there anything wrong with this setup?

---

<div class="post-metadata">

**Author:** ![betty4920taylor](https://avatars.discourse-cdn.com/v4/letter/b/cab0a1/32.png) [@betty4920taylor](https://discourse.julialang.org/u/betty4920taylor)\
**Post date:** [April 25, 2024, 5:54am UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/2 "2024-04-25T05:54:29Z")

</div>

This post was temporarily hidden by the community for possibly being off-topic, unfocused, inappropriate, or spammy.

---

<div class="post-metadata">

**Author:** ![kellertuer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kellertuer/32/220707_2.png) [@kellertuer](https://discourse.julialang.org/u/kellertuer)\
**Post date:** [April 25, 2024, 6:13am UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/3 "2024-04-25T06:13:25Z")

</div>

The on fear I see, that with the `include` instead of a dependency, you basically hide the dependency. Because in practice, you actually _do_ depend on having all functions fro your core package.

That is a bit of cheating in my view. but independent of that, you might confuse a user, that looks at the dependencies and thinks “ah, it does not depend on the core package” – and then wonders that it indeed does (just in a very hidden way, because to see the dependency he/she has to actually find the exact code line that does the include.

So, do you have a good reason for that include instead of a dependency?

In my setup (Manifolds.jl and ManifoldsBase.jl) we have separate repositories (that is not necessary, you can have them in the same I think), but I usually just have both packages in development mode.

---

<div class="post-metadata">

**Author:** ![sadish-d](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sadish-d/32/48058_2.png) [@sadish-d](https://discourse.julialang.org/u/sadish-d)\
**Post date:** [April 25, 2024, 1:47pm UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/4 "2024-04-25T13:47:04Z")

</div>

I think it hides dependency in the sense that no all the source code used in PackageFull is contained within its src folder, which is the norm others might be used to. But any dependency on external packages would show in both the Project.toml files. In any case, this is not meant to be an external package, so let’s say for now that I am not too concerned about breaking norm.

I don’t have a good reason for why I am thinking of structuring my project this way. It’s more of a why not. In my head PackageFull encapsulates PackageCore. I understand that it “feels” off, but I don’t see how this structure has more problems than having two seperate packages self-contained in their own folders. But then again, I have little experience with software development and version control.

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [April 25, 2024, 2:11pm UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/5 "2024-04-25T14:11:57Z")

</div>

If you really want to adopt the `include` strategy, it would be better to name the folder `packagecore`. I think just that much confusion will be greatly reduced.

I would not recommend that strategy, though.

---

<div class="post-metadata">

**Author:** ![kimikage](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kimikage/32/14534_2.png) [@kimikage](https://discourse.julialang.org/u/kimikage)\
**Post date:** [April 25, 2024, 2:34pm UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/6 "2024-04-25T14:34:05Z")

</div>

”In principle", there is no guarantee that the `PackageCore` exists there, since the source files in the `PackageCore/` is not known from the `PackageFull/Project.toml`.  
Future versions of julia or `Pkg.jl` may offer an option to not check out folders such as `test` or `docs` to reduce the weight.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [April 25, 2024, 2:38pm UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/7 "2024-04-25T14:38:49Z")

</div>

> Can a module in a package itself be a package?

No, but a single repo may have multiple packages in subdirectories. This is supported and used in some registered packages.

> [@sadish-d](#):
>
> I don’t add/dev PackageCore as a package/dependency from PackageFull. Rather, in `PackageFull.jl` I just `include("../PackageCore/PackageCore.jl")`.

Sure, that works, but why not just have two packages? That way their relationship is explicit, so they’re more reusable.

---

<div class="post-metadata">

**Author:** ![sadish-d](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sadish-d/32/48058_2.png) [@sadish-d](https://discourse.julialang.org/u/sadish-d)\
**Post date:** [April 26, 2024, 3:48am UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/8 "2024-04-26T03:48:59Z")

</div>

I had a very specific question in mind, but I came across a few things that I’m going to just leave here in case someone else finds them useful.

Turns out there are decent people doing all sorts of wild things when it comes to nested packages. Looks like ModelParameters.jl does the inverse of what I mentioned, equivalent to putting PackageFull is in a subfolder of PackageCore: [GitHub - rafaqz/ModelParameters.jl: Easy, standardised parameter get/set for heterogeneous or nested immutable models.](https://github.com/rafaqz/ModelParameters.jl/tree/master)

Something I hadn’t thought of is how the folder structure is going to interact with repositories. One approach suggests having a Repo folder, where the packages are in their own subfolder, but then the repo has a Project.toml and Manifest.toml: [Feature request: scan subdirs for updated versions/projects · Issue #1874 · JuliaLang/Pkg.jl · GitHub](https://github.com/JuliaLang/Pkg.jl/issues/1874#issuecomment-653762205)

And more discussion here:

> [@Usage of subdirectories to store multiple packages in a single repo](https://discourse.julialang.org/t/usage-of-subdirectories-to-store-multiple-packages-in-a-single-repo/55534/11):
>
> Thanks for pointing that out. I was unaware that building local registries like this was a practical means of registering multiple packages simultaneously. At some point, I thought I saw either @GunnarFarneback or @fredrikekre suggest that an automated flow could eventually be developed to achieve simultaneous registration. I wonder if the methodology you just outlined is the goal, or merely a temporary stepping stone (looking at a roughly 1 year timeframe, I suppose). I noticed the SnoopComp…

I don’t know where I’ll land. Some paths are more well trodden than others and the approach of using include() does not seem to be one of them.

---

<div class="post-metadata">

**Author:** ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)\
**Post date:** [April 26, 2024, 4:02am UTC](https://discourse.julialang.org/t/can-a-module-in-a-package-itself-be-a-package/113474/9 "2024-04-26T04:02:35Z")

</div>

> [@sadish-d](#):
>
> Some paths are more well trodden than others and the approach of using include() does not seem to be one of them.

It’s basically a terminology issue. Including files is fine, just don’t call an `include`-d file a package. A package has a Project.toml file (almost never should Manifest.toml be commited to Git, BTW), and if you depend on it you just put it into your Project.toml and then import it with `using` or `import`.