Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Add some pathing system #739

Closed
sewbacca opened this issue Mar 16, 2021 · 4 comments
Closed

[Feature request] Add some pathing system #739

sewbacca opened this issue Mar 16, 2021 · 4 comments
Labels
area-CraftOS This affects CraftOS, or any other Lua portions of the mod. enhancement An extension of a feature or a new feature. wontfix A bug which I won't fix or an enhancement which won't be implemented.

Comments

@sewbacca
Copy link

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.
@sewbacca sewbacca added the enhancement An extension of a feature or a new feature. label Mar 16, 2021
@Lupus590
Copy link
Contributor

Related: #152

@SquidDev SquidDev added area-CraftOS This affects CraftOS, or any other Lua portions of the mod. wontfix A bug which I won't fix or an enhancement which won't be implemented. labels Mar 16, 2021
@sewbacca
Copy link
Author

sewbacca commented Mar 16, 2021

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.

@Lupus590
Copy link
Contributor

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

I believe that both of those have been suggested already.

@SquidDev
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-CraftOS This affects CraftOS, or any other Lua portions of the mod. enhancement An extension of a feature or a new feature. wontfix A bug which I won't fix or an enhancement which won't be implemented.
Projects
None yet
Development

No branches or pull requests

3 participants