What we currently have

• with shell.setPath() you can only set the path during runtime
• same with shell.setAlias()
• we have no way for setting package.path except from within the running program

My idea

I'd like to have some general way for setting those variables and some more, if we ever need to, permanently, without using the startup file. Maybe we could use .settings for those information. If we would have a lot of different packages installed via packman or any other packaging software, each package, that brings a new bin or programs folder doesn't have to write into the startup file. I'm more interested in generalizing package.path, since there is no clean way for setting the package.path variable for every program, except by overriding the shell API.

Proposal

1. Add a setting for shell.path and shell.package.path and default them to whatever we use currently. And maybe do the same with shell.aliases as a map.
2. Add a new file .paths which contains for each usecase e.g. shell.path a list of paths. To manipulate those paths, maybe we could introduce a new api called path or paths, where you can add and remove any path for any usecase (so uninstalling gets easier, if we remove a certain path (e.g. /myprograms/bin)

Drawbacks

1. Editing a setting as a string might be complicated if you'd want to remove a certain path. First you would have to split the string, find the path that you want to remove and combine it again.
2. Adding a new config file is a bad sign in my opinion. You could evade that, by storing those tables directly into the .settings file. Still, you would need to add a new path API for that.

Related: #152

something like shell.packagePath() and shell.setPackagePath()

I believe that both of those have been suggested already.

Having a read about #152 , i agreed to @SquidDev argument about having each package as self contained files and path setups being files put inside the startup folder. However this issue is still valid for package.path, since editing this variable inside a startup file wouldn't change it globally (since package is created over and over again, when calling shell.run()). I would recommend adding something like shell.packagePath() and shell.setPackagePath(). It would be the easiest way to satisfy the requirement without breaking the self contained file paradigm. It feels very intuitive to put these functions in there, since shell.lua manages package/require, in my opinion.

Typically all this discourse happened on Discord, which makes it much harder to link to :/. Anyway, the most useful discussion happened mid December 2020 (just search for package.path, there's plenty of it).

My take is that programs should be the ones responsible for managing their package environment, not the shell.

I'm not especially happy with where things stand right now, but I don't think everyone bunging things into the path is the solution either.
What a lot of modern(tm) package managers (IRL, not in CC) do is just generate wrapper scripts which set up the environment and then launch the main program.