# Using or import search current directory?
**URL:** https://discourse.julialang.org/t/using-or-import-search-current-directory/123463
**Category:** New to Julia
**Tags:** question
**Created:** [December 4, 2024, 4:06pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463 "2024-12-04T16:06:17Z")
**Posts on this page:** 9
**Page:** 4
### Author:  [@danielwe](https://discourse.julialang.org/u/danielwe)
#### Post date: [December 6, 2024, 7:42pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/61 "2024-12-06T19:42:48Z")
> [@world-peace](#):
>
> It’s pretty rare that you want to nest modules within the same file.
It’s actually not that rare. Modules are the only way to create namespaces in Julia, and namespaces can have quite fine-grained use cases. An example is EnumX.jl, which provides an improved `@enum` using a module under the hood. It wouldn’t be very ergonomic if each enum had to live in a separate file.
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [December 6, 2024, 8:22pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/62 "2024-12-06T20:22:15Z")
> [@world-peace](#):
>
> We would like to have a way to copy and paste code into the REPL, to dynamically update it.
Do you know about the ability to enter into a module at the REPL? [The Julia REPL · The Julia Language](https://docs.julialang.org/en/v1/stdlib/REPL/#Changing-the-contextual-module-which-is-active-at-the-REPL)
* * *
This has definitely been discussed _a lot_ in the past. You can find almost all of them just by [searching for the number 4600](https://discourse.julialang.org/search?q=4600%20order%3Alatest). It’s also something that’s fundamentally very near-and-dear to folks hearts: how you prefer to organize your code is very opinionated and widely varies and can be quite different between languages.
---
### Author:  [@world-peace](https://discourse.julialang.org/u/world-peace)
#### Post date: [December 6, 2024, 10:30pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/63 "2024-12-06T22:30:03Z")
> [@mbauman](#):
>
> Do you know about the ability to enter into a module at the REPL?
I did not know about that, that is interesting, thanks for the tip.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [December 6, 2024, 11:06pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/64 "2024-12-06T23:06:47Z")
> [@world-peace](#):
>
> I don’t know why they didn’t just do the Rust/Python thing which works really well.
Maybe I’m just misinterpreting this, but how is `include`-ing a file to evaluate an unpackaged module and importing its names into other modules substantially different from Rust’s option to insert a file’s text into a `mod` definition and `use` to import names into other modules? Rust even made that decision despite 1-file-per-module being idiomatic, see [Why would rust use both mod and use? - help - The Rust Programming Language Forum](https://users.rust-lang.org/t/why-would-rust-use-both-mod-and-use/77045/5)
> [@world-peace](#):
>
> there is intentionally a strong distinction between a package and a module.
Well, yes. Packages are (and must be) modules, but not all modules are packages. An installed, versioned, and compiled unit can’t be handled the same way as your own source code. Rust has packages, crates, and `mod`-ules too. If anything it seems like Python is the odd one out here.
> [@world-peace](#):
>
> Who said anything about changing the file contents? This isn’t what I am doing
>
> > [@Benny](#):
> >
> > You need `importlib.reload` to actually reload the module
>
> This is the exact behaviour I am trying to avoid. Re-loading from disk
Sorry, I likely misunderstood your intent, specifically your post’s phrasing “dynamically load and replace code” and “dynamically replace types, functions, modules and packages.” That said, I’m evidently not alone in failing to see what the intent is; all this stuff about imports don’t really seem relevant to your initial Python example for reassigning `exampleModule1` to a different function in the REPL.
---
### Author:  [@mhinsch](https://discourse.julialang.org/u/mhinsch)
#### Post date: [December 9, 2024, 9:22am UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/65 "2024-12-09T09:22:34Z")
I largely agree with that assessment.
A positive effect of this discussion has been that it prompted me to read up on the details of the module/package system again. This made me realise that I had misunderstood a few things and that the system is actually very consistent.
However, in my opinion there are two issues:
- Having `use`/`import` handle modules _and_ packages without any obvious visible difference on the users’ side leads to endless amounts of confusion, especially for people coming from languages with a file ↔ module correspondence.
- There is no obvious, lightweight solution for the (in my mind very common) use case “encapsulate a local chunk of code and load it like a package”.
---
### Author:  [@danielwe](https://discourse.julialang.org/u/danielwe)
#### Post date: [December 9, 2024, 8:20pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/66 "2024-12-09T20:20:10Z")
> [@mhinsch](#):
>
> There is no obvious, lightweight solution for the (in my mind very common) use case “encapsulate a local chunk of code and load it like a package”
The lightest-weight solution is probably to modify `LOAD_PATH` manually. Although this has been discouraged previously in the thread, there’s currently no alternative if you want to load modules like packages without dealing with the overhead of creating a new package.
Although it’s not framed this way, the manual section on [package directories](https://docs.julialang.org/en/v1/manual/code-loading/#Package-directories) is really an explanation of how Julia deals with entries in `LOAD_PATH` that don’t have the full structure of a package. It’s not written in a user-friendly way, so here’s the CliffsNotes version:
- Put your code in a file
- Wrap it in a top-level module such that the module name exactly matches the file name
- Put the file in the package directory\[1\]
Now the module can be loaded like a package. Example:
- My package directory is `./code`
- It contains a single file `code/Foo.jl` with the following contents:
```julia
module Foo
export foo
foo() = println("Hello from Foo.jl")
end
```
- Now let’s load `Foo` like a package:
```julia
julia> push!(LOAD_PATH, "code"); # add ./code to LOAD_PATH
julia> using Foo
[Info: Precompiling Foo [top-level]
julia> foo()
Hello from Foo.jl
```
I think this is the closest you can currently get to a python-like `import .file` experience. The only extra overhead is making sure the module and file names match, and a single push to `LOAD_PATH`.
* * *
1. Alternatively, put the file in a package-like folder structure inside the package directory, that is, instead of adding `Foo.jl` you can add `Foo/src/Foo.jl`
---
### Author:  [@mhinsch](https://discourse.julialang.org/u/mhinsch)
#### Post date: [December 9, 2024, 8:41pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/67 "2024-12-09T20:41:51Z")
Yes, I’ve been doing that for my own projects for a while. The problem is that this stops working as soon as a `project.toml` exists, since then all package dependencies have to be declared explicitly.
---
### Author:  [@danielwe](https://discourse.julialang.org/u/danielwe)
#### Post date: [December 9, 2024, 8:56pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/68 "2024-12-09T20:56:18Z")
Can you give an example of when this occurs? (None of the previous examples in the thread use package directories.) I assume you’re referring to something caused by the following rules (from the manual):
> 1. A package with a project file cannot depend on one without a project file since packages with project files can only load packages in `graph` and packages without project files do not appear in `graph`.
> 2. A package with a project file but no explicit UUID can only be depended on by packages without project files since dummy UUIDs assigned to these packages are strictly internal.
---
### Author:  [@mhinsch](https://discourse.julialang.org/u/mhinsch)
#### Post date: [December 9, 2024, 9:03pm UTC](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463/69 "2024-12-09T21:03:04Z")
I assume that’s the reason, yes. In practice I realised it when I started preparing a package from a project I had only used locally until then.
[Previous page](https://discourse.julialang.org/t/using-or-import-search-current-directory/123463.md?page=3)