### Author:  [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)
#### Post date: [May 15, 2023, 11:06pm UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/3 "2023-05-15T23:06:36Z")
If this were to be implemented, I definitely think it should try to treat the current working directory as a package. It would be awesome to be able to share a project with someone and just tell them to run `julia -m MyPackage`. I know that this is equivalent to having a `script.jl` file someone could run, but I think the `-m` syntax is nicer.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [May 15, 2023, 11:23pm UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/4 "2023-05-15T23:23:07Z")
> [@mrufsvold](#):
>
> run `julia -m MyPackage`. I know that this is equivalent to having a `script.jl`
I don’t think so. I mean it doesn’t seem warranted just for a synonym (is that what happens in Python?). It should look up the (precompiled) module in a package, that you must have preinstalled. Same as in Python. What I mention as a possiblity, an empty env., is probably nonsensical.
Python needs to compile projects you run, and store somewhere. I don’t think that ever happens, no more than for individual Julia files. Is that something we could or would want for julia, then store in same directory? And possibly have the “zipfile” option Python has (see fuller updated quote in my previous comment).
[One other thing, Python has .py and .pyw (for pythonw) on Windows. Julia also needs the endings .jl and e.g. .jlw on Windows. Not sure it enters into this discussion.]
>
---
### Author:  [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)
#### Post date: [May 16, 2023, 12:06am UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/5 "2023-05-16T00:06:29Z")
In Python, any directory can become a package by adding a ` __init__.py` flag. You can make the package executable by adding a ` __main__.py` file. All the packages in your current working directory are available to run or execute. So this works:
```python
# my_pkg/ __main__.py
print("hello world")
```
```bash
$ python -m my_pkg
hello world
```
However, the dependencies of that package are not guaranteed. Everything gets executed in whatever the current environment is, and this environment is where all the compiled code is stored.
For Julia, since we have such nice built-in dependency management, I think the logic would be more like
1. User calls `-m` flag on `x` module name.
2. Look for modules installed in current environment, if found, run it.
3. Look for packages in the current working directory. If found, activate its environment, instantiate, and run it.
---
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [May 16, 2023, 12:17am UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/6 "2023-05-16T00:17:23Z")
> [@mrufsvold](#):
>
> Look for packages in the current working directory. If found, activate its environment
Does this make sense? I mean, in Python you can run an installed package or code in the working directory, and maybe that’s useful, but at least I think it will be similarly fast.
In Julia you can define a module and have it in some file, but I’m not even up-to-speed if you can have packages in your current directory. I’ve never made a package, only addationally deved packages from others. They are always under .julia. I suppose you’re right and they could be local when you first dev then before registration, and now curious are they handled the same, i.e. precompiled.
I don’t know if we need installed packages and in current dir, but if there’s a huge speed penalty, then I’m not sure we want that option, rather only support installed packages? Possibly this 3rd option could be skipped and always added later (defer that decision)? Or would it be a braking change?
---
### Author:  [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)
#### Post date: [May 16, 2023, 12:36am UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/7 "2023-05-16T00:36:33Z")
I hear your argument, for sure. We need to consider start time and its impact on useability. I would be behind adding the feature for installed packages only as a starting point!
I have two points where I’d push back though.
First, when I share a project with someone who doesn’t normally use Julia, I need to tell them to do the following:
```julia
$ git clone https://github.com/mrufsvold/mypackage
$ cd mypackage
$ julia
julia> ]
pkg> activate .
pkg> instantiate
julia> include("script.jl")
```
Alternatively, I can, of course, wrap the julia logic up in a script, but it’s a little silly to have to add the Pkg dance to the top when it’s the same for everyone.
My proposal is to just wrap up all that logic as automatic so that the following would do the same:
```julia
$ git clone https://github.com/mrufsvold/mypackage
$ julia -m mypackage
```
It’s the same speed, but yields less redudancy for me and mental overhead for my colleague.
Second, as long as you’re activating the project’s enviornment, code caching should still apply, so while there is certainly a tradeoff to be considered about the speed of the top-level logic, the dependencies would still be precompiled and fast after first use.
---
### Author:  [@mrufsvold](https://discourse.julialang.org/u/mrufsvold)
#### Post date: [May 16, 2023, 12:50am UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/8 "2023-05-16T00:50:13Z")
I’m re-reading @pankgeorg original proposal, and I’ve definitely got astray here 😅 I brought too much of my python background to the conversation, I think.
I like the simple, understandable idea of `-m package == using package: package`, but it is incongruent with my idea of wrapping up instantiation and such to make local projects runnable. I retract my proposal, because explicitness is good.
---
### Author:  [@jling](https://discourse.julialang.org/u/jling)
#### Post date: [May 16, 2023, 3:38am UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/9 "2023-05-16T03:38:38Z")
> [@mrufsvold](#):
>
> because explicitness is good.
yes, even Python agrees nominally:
> - Explicit is better than implicit.
but as we all know, the idea of importing dir / files as “pkg” is super confusing and I think we should avoid borrowing that idea in Julia…
---
### Author:  [@pankgeorg](https://discourse.julialang.org/u/pankgeorg)
#### Post date: [January 2, 2024, 2:32pm UTC](https://discourse.julialang.org/t/idea-new-julia-cli-switches-m-and-pkg/98897/11 "2024-01-02T14:32:08Z")
an improved version of this is being adopted upstream! [Introduce -m/--module flag to execute a `main` function in a package by KristofferC · Pull Request #52103 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/52103)