# Import types "above" a module with ..: for consistency and brevity?

**URL:** <https://discourse.julialang.org/t/import-types-above-a-module-with-for-consistency-and-brevity/36754>\
**Category:** General Usage\
**Tags:** module\
**Created:** [March 30, 2020, 6:17pm UTC](https://discourse.julialang.org/t/import-types-above-a-module-with-for-consistency-and-brevity/36754 "2020-03-30T18:17:45Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)\
**Post date:** [April 3, 2020, 1:00am UTC](https://discourse.julialang.org/t/import-types-above-a-module-with-for-consistency-and-brevity/36754/6 "2020-04-03T01:00:56Z")

</div>

Here’s a link to the new post about first-class support for local, unregistered packages.

> [@Could we make first-class support for packages that are "just files" and not repositories?](https://discourse.julialang.org/t/could-we-make-first-class-support-for-local-unregistered-packages/36931):
>
> I keep circling around the same issue from a variety of different vantage points, and I think that having first-class support for local, unregistered packages (just local files, not repositories) would solve a lot of problems that I see in structuring Julia programs. We have a repo that has our aircraft simulation in it. The current package manager does a great job of managing our dependence on external packages, like HDF5 and YAML. I love it. We also have local modules for reusable functional…

---

_[View the full topic](https://discourse.julialang.org/t/import-types-above-a-module-with-for-consistency-and-brevity/36754)._