MIX_PATH environment variable (of sorts)

[alexrp]

Basically, the idea is that we'd like to be able to say:

export MIX_PATH=~/.mix

The path assigned to MIX_PATH is expected to contain an exactly one-level hierarchy of directories. E.g.:

$ tree .mix
.mix
└── flect
    └── compile.flect.exs

(Reasoning for the directory hierarchy: Making it easier to clone Git repos in there.)

Mix should then go into each directory in MIX_PATH and load the .exs (.ex too?) files and load up all tasks it finds.

[josevalim]

I am a bit confused. I thought the original idea was to allow many directories in MIX_PATH? As in MIX_PATH=~/.mix;/some/other/path. I am not sure I am comfortable with it recursively looping everything in the path.

[alexrp]

I thought a bit about it and figured it would be cumbersome to add so many paths if you're using many community tasks.

I don't think recursively grabbing tasks like that will be a problem in practice. It's certainly no worse than having a ~/.elixir/foo.exs or whatever.

[josevalim]

The way MIX_PATH works is by loading the beam files in the path. Loading everything recursively can have side effects and load beam files you do not expect to.

If the goal is to install other tasks we already have mix local and I'd recommend to simply rely on it.

[alexrp]

The way MIX_PATH works is by loading the beam files in the path. Loading everything recursively can have side effects and load beam files you do not expect to.

We can make a simple convention then: Mix loads $MIX_PATH/*/task.exs which is expected to load whatever is necessary to use the particular tasks. That way, there's about as much room for error as there is with pointing MIX_PATH to particular files.

If the goal is to install other tasks we already have mix local and I'd recommend to simply rely on it.

mix local.install expects shell input. It's not exactly suitable for a make install task.

[josevalim]

We can make a simple convention then: Mix loads $MIX_PATH/*/task.exs which is expected to load whatever is necessary to use the particular tasks.

That would be giving users an option to shoot themselves in the foot. It would mean we would need to load all task.exs files in MIX_PATH every time they run a mix command because those tasks could be doing something.

We support beam files. We could possibly support .ex tasks that are compiled when they are installed but that is it.

mix local.install expects shell input. It's not exactly suitable for a make install task.

Maybe have a mix local.path that prints the path so you can do whatever you want with it?

[alexrp]

That would be giving users an option to shoot themselves in the foot. It would mean we would need to load all task.exs files in MIX_PATH every time they run a mix command because those tasks could be doing something.
We support beam files. We could possibly support .ex tasks that are compiled when they are installed but that is it.

I don't particularly care what format they are in. Just s/.exs/.beam/ in my previous comment and I'd be happy all the same.

Maybe have a mix local.path that prints the path so you can do whatever you want with it?

This is still bad. When a makefile is told to install to a particular prefix, it should install there and nowhere else. Angry package maintainers would hunt us down with axes if we encouraged this. :)

But this is a separate issue from the proposal here itself IMHO.

[josevalim]

This is still bad. When a makefile is told to install to a particular prefix, it should install there and nowhere else.

Agreed. That's why I think MIX_PATH should be a list of paths separated by ;.
As I don't believe we should iterate one existing path recursively.

[alco]

Agreed. That's why I think MIX_PATH should be a list of paths separated by ;.

Better :, in the UNIX tradition. ; is for windows.

[josevalim]

Is this still relevant? If not, I'd rather close this until someone needs a similar feature again.

[alexrp]

Well, I still need this feature.