# How can we create a leaner ecosystem for Julia?

**URL:** <https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904>\
**Category:** Statistics\
**Tags:** package, proposal, time-series, machine-learning\
**Created:** [January 3, 2020, 1:35am UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904 "2020-01-03T01:35:55Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [January 5, 2020, 8:22am UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/41 "2020-01-05T08:22:36Z")

</div>

I’m not really worried about that kind of thing happening to me, but it needs to be acknowledged that there is some dilution of attribution in moving to an org that could get complicated when a project has been funded by a private organization – who needs to get modelling contracts in future. Or when academic publishing is involved.

I think we need more discussion of this - people have real reasons for keeping their packages out of organizations, even though we know that it’s detrimental overall. It’s a classic common property dilemma, and they often require clear rules and standards to solve.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 5, 2020, 8:28am UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/42 "2020-01-05T08:28:20Z")

</div>

> [@juliohm](#):
>
> What is being discussed here is not curation. It is organization of research and integration across different packages in a given domain.

Frankly, from rereading this topic I am not quite sure what exactly is being discussed or proposed here.

The desired _outcome_ is pretty clear:

1. there should be more high-quality, well-maintained Julia packages that
2. interoperate nicely, and
3. it should be easier to find them.

Generally this is accepted as a reasonable goal for all languages.

What is not clear is that this should come from a “centralized” effort. As usual, the devil is in the details: suppose that, as you are proposing,

> [@juliohm](#):
>
> each domain on Discourse could have a set of coordinators organizing the existing features, packages, what is missing, etc.

So let’s say that the coordinators for domain X identify Y as a missing feature. What happens then?

Do they just implement it — then why do we need the extra organizational layers for this, instead of just someone making a PR? If they don’t implement it, then what’s the value added, given that most packages are well aware of missing features (and if not, someone can just open an issue?)

Similarly, I am not sure that those who propose that

> [@juliohm](#):
>
> packages with tags could be reviewed in the General registry. At the moment the bot gives time to merge new packages, but rarely someone from the domain reviews the work or adds it to a pool of packages in a coherent way. We can have guidelines for coordinators or reviewers.

have thought about the details of this process. Reviewing someone else’s code is a rather significant investment of time, but let’s suppose you find people to do this.

How is this different from just reviewing code and making a PR at an arbitrary point in the package lifetime? What happens when the suggestions are ignored for a while (because the author is busy), does this hold up registration? What if they are rejected outright, if the original author has a different programming style or vision for the package?

I would suggest that instead of proposing some centralized scheme, people interested in things like these should just experiment with the idea on a voluntary basis. To echo the point made by @fipelle: there is nothing here that requires concerted effort from the _whole_ Julia community.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [January 5, 2020, 10:25am UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/43 "2020-01-05T10:25:54Z")

</div>

> [@fipelle](#):
>
> I am not sure I agree with the idea of having a more centralised community, or with the idea of having domain experts in charge of leading the way. This seems quite the opposite of what open source generally is, and it would not be clear how to select those experts.

@fipelle I don’t see how it is the opposite of open source. Having an organized community doesn’t imply that we can’t be open source. It is like assuming that open source needs to be disorganized. I understand that everyone should have the freedom to do whatever they want online, open source their work, and so on. But like journal papers are reviewed by people working in a domain for years, software that is published on the General registry could be at least notified to people working with Julia for years in a specific domain. Notification is not review, however; it is just a means by which we can organize things, and offer suggestions to authors about where things could be placed compared to prior art.

> [@Tamas\_Papp](#):
>
> So let’s say that the coordinators for domain X identify Y as a missing feature. What happens then?
> 
> Do they just implement it — then why do we need the extra organizational layers for this, instead of just someone making a PR? If they don’t implement it, then what’s the value added, given that most packages are well aware of missing features (and if not, someone can just open an issue?)

After identifying a missing feature, coordinators can aggregate this information in a single place for potential contributors to be aware of and submit PRs. If someone ends up publishing a package that addresses the limitation, then coordinators can check off the item from the list of missing features and discuss with the package author how to improve integration with the existing stack.

> [@Tamas\_Papp](#):
>
> Reviewing someone else’s code is a rather significant investment of time, but let’s suppose you find people to do this.

I know well. As a reviewer of JOSS papers for Julia packages, I understand the commitment. It is like reviewing journal papers for scientific journals like some of us do.

> [@Tamas\_Papp](#):
>
> How is this different from just reviewing code and making a PR at an arbitrary point in the package lifetime?

I don’t know if I understood the question. It seems disconnected from the rest of the discussion. We are not discussing code review in a strict sense as you describe. We are discussing organization of domain efforts, and things that are more high-level that always happen in scientific communities. Keep in mind that the Julia community is very unique in the sense that many of us have PhDs or joined the language during a PhD seeing the value added. I think we should take advantage of this uniqueness somehow while publishing software. It is a differentiating feature of the community that is rarely discussed.

Overall, and coming back to the original question in the thread, I do believe that we would benefit from an organization of the community into domains of expertise for better integration of the work that is being done out there. GitHub organizations partially solve this issue, but more important than that is a method to be notified of all efforts in a given domain. Two methods have been proposed so far that I think are interesting: notifications for coordinators on Discourse and on the General registry whenever a package is tagged with domain keywords. To pursue these methods, however, one needs an additional method to startup a minimum set of coordinators for each domain.

For creating an initial set of coordinators, we could perhaps use the GitHub organizations that already exist. People showing interest could add their name to a shared document on a GitHub repository that would be checked out by some script in the General registry to notify users if that is possible.

---

<div class="post-metadata">

**Author:** ![Datseris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/datseris/32/13406_2.png) [@Datseris](https://discourse.julialang.org/u/Datseris)\
**Post date:** [January 5, 2020, 10:47am UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/44 "2020-01-05T10:47:32Z")

</div>

> [@Raf](#):
>
> But I don’t think it’s always as simple as you suggest. In this case it’s important that cesar gets some credit for paying for all the work I’ve done. Moving something to an org also complicates who eventually publishes the methods papers - that’s where having my name on it actually does matter to me.

I need to address this, because the way you present this is just not true. First of all, GitHub has a very, _very_ clear presentation of exactly who, and by how much, has contributed to a repository: it is the “Contributors” page. There, noone can alter or take credit from you, regardless of where this package is located. And in my eyes, this should be the number 1 way a community measures credit regarding a repo.

Since you are clearly the main contributor to some repo DynamicGrids.jl, you can clearly show this to your company, even if your repo is located elsewhere.

Now, regarding papers and authors: both RecurrenceAnalysis.jl and Agents.jl, which are packages that joined the org. JuliaDynamics, have papers associated with them. The authors of these papers are the original developers of the packages. I am a scientist, so for me who is an author of a paper is daily life. By now for me it is generally clear who must be author, who could be and who has no reason to be.

---

<div class="post-metadata">

**Author:** ![heliosdrm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/heliosdrm/32/3851_2.png) [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)\
**Post date:** [January 5, 2020, 12:13pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/45 "2020-01-05T12:13:35Z")

</div>

Adding to this, in Julia packages there is room to acknowledge authorship in the `Project.toml` file, and some also include a `CITATION.bib` where you can define how you want the package to be cited. Repository owners — whether they are the authors, coordinators of an organization, or just people who forked or copied code from others — may/should use those resources to give proper credit.

Those are resources that are set up manually, not an automatic tool like the “Contributors” tab. Each way has its benefits and limitations, but are complementary to each other.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [January 5, 2020, 12:26pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/46 "2020-01-05T12:26:51Z")

</div>

Ok those are good points. But… ownership is really practically different to commit record, in many ways.

- Ownership is much easier to demonstrate to lay observers than git commits. Seriously, who understands what the commit record means.
- Ownerership gives veto power over new pull requests and changes, which you lose in an organization. This is especially important if you are paid to make something to work a certain way.
- When a package is in a private organizations page, they are quite clearly credited as the creators of it.
- If the package moves to a Julia organization, the money and time an organization put in is no longer apparent - it will just look like I the developer, personally, did all the contribution based on commits. But I actually have collaborators who don’t write much code.

To be clear, I agree with you mostly, but I think you are wrong to believe that things _mostly_ working out ok is enough for a functional collective commons. Lack of clarity over rewards disincentivises contribution from some proportion of the population, and we need to understand how that works to minimize it. People interested should read a few of Elinor Ostroms books on common property governance.

(Also, to be clear, I actively work on packages in multiple julia orgs)

---

<div class="post-metadata">

**Author:** ![Datseris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/datseris/32/13406_2.png) [@Datseris](https://discourse.julialang.org/u/Datseris)\
**Post date:** [January 5, 2020, 12:34pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/47 "2020-01-05T12:34:25Z")

</div>

I see. These, and more especially the last one, are some fair points that I haven’t considered, mostly because I’ve never worked in corporate settings.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [January 5, 2020, 12:35pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/48 "2020-01-05T12:35:47Z")

</div>

I actually work in science research (ecology) in a small org that needs to win contracts. Recognition can be useful for that.

---

<div class="post-metadata">

**Author:** ![heliosdrm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/heliosdrm/32/3851_2.png) [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)\
**Post date:** [January 5, 2020, 12:37pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/49 "2020-01-05T12:37:04Z")

</div>

> [@Raf](#):
>
> When a package is in a private organizations page, they are quite clearly credited as the creators of it.

Normally yes, but it does not need be like that. We are talking about free software, so you are allowed to create a repo on your private page with code that is completely made by another person. The repository name is not useful to acknowledge authorship in that case.

---

<div class="post-metadata">

**Author:** ![Raf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/raf/32/3383_2.png) [@Raf](https://discourse.julialang.org/u/Raf)\
**Post date:** [January 5, 2020, 12:40pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/50 "2020-01-05T12:40:19Z")

</div>

Cmon, we are talking about the actual registered julia package, with github stars, forks, etc. It has multiple references to establish legitimacy, and it does matter.

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [January 5, 2020, 12:57pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/51 "2020-01-05T12:57:22Z")

</div>

I think there’s been some good discussion here but it’s difficult to make any progress with so many different problems that are trying to be solved at once. If people have a single thing that’s been identified that they care about it may be helpful to have a dedicated thread or raise and issue in the appropriate repository/organization.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [January 5, 2020, 1:00pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/52 "2020-01-05T13:00:12Z")

</div>

Linking other example of package that could possibly be merged into existing efforts had the authors agreed on a generalized interface: [Diagonalizations.jl: a package for multivariate linear filtering](https://discourse.julialang.org/t/diagonalizations-jl-a-package-for-multivariate-linear-filtering/32990)

---

<div class="post-metadata">

**Author:** ![Zach\_Christensen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/zach_christensen/32/7220_2.png) [@Zach\_Christensen](https://discourse.julialang.org/u/Zach_Christensen)\
**Post date:** [January 5, 2020, 1:19pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/53 "2020-01-05T13:19:24Z")

</div>

> [@heliosdrm](#):
>
> Normally yes, but it does not need be like that. We are talking about free software, so you are allowed to create a repo on your private page with code that is completely made by another person. The repository name is not useful to acknowledge authorship in that case.

How contributions are acknowledged matters in different ways for different people. If you are trying to build a personal career that demonstrates competency in creating algorithms it’s not enough to be coauthor on many papers. You need to be first author on some in a completely unambiguous way. If you are trying to demonstrate that your lab/workgroup is responsible for making serious advancements in a field then attributing individual contributions may not translate into credit for that work group. I’m sure that there many other nuances I’m not considering but I just want to make a point that we can’t just assume the same tools solve the same problems for everyone.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [January 5, 2020, 2:38pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/54 "2020-01-05T14:38:39Z")

</div>

To add to the discussion on GitHub organizations, [evidence](https://discourse.julialang.org/t/diagonalizations-jl-a-package-for-multivariate-linear-filtering/32990/4) indicates that that they do not always improve discoverability of packages. I personally never search packages based on organizations. I do Google search or use [https://pkg.julialang.org](https://pkg.julialang.org) search. However, these organizations may boost the credibility of packages found via other methods, and thus create a collaboration hub. They also may increase the willingness of others to contribute with code.

---

<div class="post-metadata">

**Author:** ![juliohm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/juliohm/32/215266_2.png) [@juliohm](https://discourse.julialang.org/u/juliohm)\
**Post date:** [January 5, 2020, 2:46pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/55 "2020-01-05T14:46:26Z")

</div>

And another link on how to organize contributions via the concept of contributorship, which is becoming popular in journals: [Publications | Free Full-Text | Contributorship, Not Authorship: Use CRediT to Indicate Who Did What | HTML](https://www.mdpi.com/2304-6775/7/3/48/htm)

---

<div class="post-metadata">

**Author:** ![chakravala](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chakravala/32/6832_2.png) [@chakravala](https://discourse.julialang.org/u/chakravala)\
**Post date:** [January 5, 2020, 3:00pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/56 "2020-01-05T15:00:07Z")

</div>

Github organizations cannot be _followed_ on github.

It often bothers me that I can’t follow a github organization to see when new packages are created.

---

<div class="post-metadata">

**Author:** ![fipelle](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fipelle/32/4772_2.png) [@fipelle](https://discourse.julialang.org/u/fipelle)\
**Post date:** [January 5, 2020, 3:05pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/57 "2020-01-05T15:05:28Z")

</div>

I think we really need to clear what is the problem you are trying to solve.

> [@juliohm](#):
>
> Having an organized community doesn’t imply that we can’t be open source. It is like assuming that open source needs to be disorganized.

Open source needs to be free. If you want to have a centralised community you need to have mandatory requirements and binding reviews by domain experts (the selection process would deserve a separate and long discussion).

In my view, we are choosing between two different scenarios:

- **current conditions:** open to organised and independent development (via orgs and individuals). This could result more easily in duplicate packages. However, user have more options (Individually, each package does not contribute much, but they contribute collectively).

- **centralised community:** open to organised development, mostly closed to independent packages. Less duplicate packages. Users have less options.

In both cases users need to be able to filter _the internet_ and find the right package for their needs. However, in the second case we will probably see the creation of some sort of alternative register for independent developers (or in the creation of a broad range of non-registered packages). This could make this whole process more complicated.

Furthermore, in the case of an organised community developers will enter in typical _bounded rationality_ problem, since they will have to decide what goes into a large package, trying to interpret users desire.

> [@juliohm](#):
>
> Notification is not review, however; it is just a means by which we can organize things, and offer suggestions to authors about where things could be placed compared to prior art.

If you believe that we have too many packages doing the same thing because people want to have ownership on their code, then I do not see how a notification system could do it - since it can be simply ignored.

> [@juliohm](#):
>
> To add to the discussion on GitHub organizations, [evidence](https://discourse.julialang.org/t/diagonalizations-jl-a-package-for-multivariate-linear-filtering/32990/4) indicates that that they do not always improve discoverability of packages

If the discussion is about incentives and the use of GitHub orgs then it might be best to split the post or change the title.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [January 5, 2020, 3:43pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/58 "2020-01-05T15:43:53Z")

</div>

> [@fipelle](#):
>
> in the second case we will probably see the creation of some sort of alternative register for independent developers

Fortunately, I don’t think that tightening review/acceptance requirements for the General registry is considered. My understanding is that any kind of review/curation/quality control [is encouraged to take place](https://github.com/JuliaLang/Pkg.jl/issues/353) in other registries, maintained by organizations etc.

If someone believes that a centralized process for this can/should be organized, they should just go ahead and create a registry for that, and then we can see how it works.

---

<div class="post-metadata">

**Author:** ![Ali\_Vahdati](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ali_vahdati/32/38715_2.png) [@Ali\_Vahdati](https://discourse.julialang.org/u/Ali_Vahdati)\
**Post date:** [January 5, 2020, 3:49pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/59 "2020-01-05T15:49:26Z")

</div>

> [@Datseris](#):
>
> I think this was a really successful thing with RecurrenceAnalysis.jl and Agents.jl where I believe both packages saw both real code improvements, but also increase in popularity, after they joined. But @heliosdrm and @Ali_Vahdati should say for themselves, they were the original owners.

I agree with what’s said here. I’d like to add an extra benefit of joining an organization for developers: you get other people to think and comment about problems you care and have thought about. This can be very rewarding and instructive. I, at least, learned a lot along the way.

---

<div class="post-metadata">

**Author:** ![Amin\_Yahyaabadi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/amin_yahyaabadi/32/9826_2.png) [@Amin\_Yahyaabadi](https://discourse.julialang.org/u/Amin_Yahyaabadi)\
**Post date:** [January 5, 2020, 4:23pm UTC](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904/60 "2020-01-05T16:23:01Z")

</div>

New redundant packages appear because it is usually hard to merge pull requests into current repositories. Also, people don’t reuse code because of the reasons that I will state in the following.

My personal experience offers that there are a couple of patterns that repeat regarding this topic

- When a package’s development is stopped or not worth it:  
E.g.: **PackageCompiler and PackageCompilerX** : the development of the PackageCompiler is very slow or stopped, and there is that JuliaCon youtube on how to rewrite PackageCompiler. That is why PackageCompilerX has emerged.  
Many other examples fit under this.

- When developers of a package don’t want extra features:  
E.g.: **Julia-Client and Juno-Plus** : I submitted a PR to Julia-Client, however developers thought that Juno-Plus has too many extra features that should not be inside Julia-Client, and so the 2nd one got emerged.

- When a package’s developer wants to minimize dependencies.  
E.g.: **PrettyTables and AcuteML** : despite all of the benefits of using another advanced package, the developer thought using AcuteML as the HTML backend will increase the overall loading time of the package.

- It is hard to become a member of an organization:  
Requires contacting the main owner.

- Lack of package tagging:  
Many mentioned this already in this thread.

- Lack of documentation:  
**Static Linter, Language Server** are examples of packages with zero documentation. That is why no one knows how to use them anywhere else other than in VSCode.

- Not allowing overriding a method:  
Overriding a method in Julia will result in an `incremental precompilation` warning. If someone wants to use some code but wants to override a method, they should either write the code from scratch or make a fork of the original package and edit the function there. However forks are not supported in Project.toml, and Manifest.toml files aren’t as nice as Project.tomls.

- When people want to make a portfolio:  
In this case, people usually tend to write everything from scratch. And those, who have written a package on their own, tend to disagree with merging other’s people PRs.

A solution to some of these problems is allowing to have multiple packages in a repository:

> <https://github.com/JuliaLang/Pkg.jl/issues/1251>
>
> Currently, a single Git repository can only contain one registered package, whic…h must live in the top folder of the Git repository.
> 
> I would like to request the ability to store more than one registered package in the same Git repository.
> 
> For example, I might have two packages \`Foo\` and \`Bar\` that I store in a single GitHub repository \`DilumAluthge/FooBar.git\`. In this case, the contents of \`https://github.com/DilumAluthge/FooBar.git\` might look something like this:
> \`\`\`
> FooBar
> ├── Bar
> │ ├── Project.toml
> │ ├── src
> │ │ └── Bar.jl
> │ └── test
> │ └── runtests.jl
> └── Foo
> ├── Project.toml
> ├── src
> │ └── Foo.jl
> └── test
> └── runtests.jl
> 
> 6 directories, 6 files
> \`\`\`
> 
> For example, the contents of \`https://github.com/DilumAluthge/FooBar.git\` might instead look something like this:
> \`\`\`
> FooBar
> ├── myfolder
> │ └── Foo
> │ ├── Project.toml
> │ ├── src
> │ │ └── Foo.jl
> │ └── test
> │ └── runtests.jl
> └── otherfolder
> └── subfolder
> └── Bar
> ├── Project.toml
> ├── src
> │ └── Bar.jl
> └── test
> └── runtests.jl
> 
> 9 directories, 6 files
> \`\`\`
> 
> \---
> 
> \## Possibly related issues/pull requests:
> 
> \- #691: "Allow packages to live in a directory of repo"
> - This issue discusses relaxing the requirement that a package is located in the top folder of the Git repository. However, the issue doesn't discuss whether or not you would be allowed to have multiple registered packages in the same Git repository.
> 
> \- #1233: Proposal for "sub-projects"
> - This issue discusses sub-projects. However, a sub-project is an "incremental addition of packages to an already existing main-project". This is different from what I am proposing here, in which there is no "main project" from which the other projects derive.

or allowing to load a subset of a package

> [@Is it possible to load a subset of a package?](https://discourse.julialang.org/t/is-it-possible-to-load-a-subset-of-a-package/31136):
>
> I have run into issues with long loading times for using some of my custom packages, and it appears to be because those packages load a lot of dependencies (as suggested [here](https://discourse.julialang.org/t/very-slow-pre-compiling-and-using-of-custom-julia-package/24708/2)). But often my packages only need some small subset of the functionality provided by another package (e.g., I only need gradient from ForwardDiff). So, I have two questions: Is there a way to only load a subset of a package? (I.e., something like using ForwardDiff: gradient, but only load code related to gradient instead…

[Previous page](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904.md?page=2)

[Next page](https://discourse.julialang.org/t/how-can-we-create-a-leaner-ecosystem-for-julia/32904.md?page=4)