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

Mega rejig! #140

Merged
merged 7 commits into from
Nov 29, 2017
Merged

Mega rejig! #140

merged 7 commits into from
Nov 29, 2017

Conversation

davestephens
Copy link
Collaborator

I've rejigged a few paths of what lives in where with the idea of it being more Docker friendly.

This looks like a massive change, but it's not really. I'll run through each thing I've changed and why:

  • Created /config and moved menu.hjson, prompt.hjson and set the default config creation/load path to the same path.

    • This moves all config-y type stuff to the same place, meaning you can mount /config as a volume and Enig will load these directly. (Right now the Docker image grabs the files from the volume and injects them into the right place within the Enig directory structure.
  • Moved /mods/art -> /art/general, moved /mods/themes -> /art/themes, moved actual mods within /mods into /mods/system.

    • Bit of an OCD rejig :-) Also means the "non-theme" art can be directly mounted as a Docker volume, as can themes.
  • Created mods/user

    • Can be mounted as a /mods volume with Docker so a user can add their own custom stuff. This has been added to getModulePaths, but will probably need a little work and testing so that menu_util.js works cleanly with it (ie bits where Config.paths.mods is referenced).

@NuSkooler
Copy link
Owner

Nice work! I've only skimmed through the changes so far, but overall this sounds good. With such big changes, I'll have to do some heavy testing.

Some additional comments:

  • I like that menu.hjson, config.hjson, and prompt.hjson end up living in the same place. The system already has --config option -- I wonder if it should specify a directory vs a file now.
  • I think the "system" modules could live in /core really. If they are truly system, they probably shouldn't be called a "mod". This is something I've needed to clean up for a long time. That would allow for simply /mods for the user mods.

Last two things off the top of my head for this to land in a main branch:

  • Documentation. There isn't much, but adjustments will be made where any of these paths are made.
  • Some kind of conversion tool (oputil.js upgrade type system would be slick)

Thoughts?

@davestephens
Copy link
Collaborator Author

davestephens commented Nov 23, 2017

Glad you're up for the change, I think it'd make things less complicated overall. :-)

Addressing your points in order:

  • Yeah, agreed. This would also make the code that locates config and prompt/menu.hjson simpler.
  • When I created the CombatNet module (now live on force9! :)) - I didn't even consider the mods directory. Are there any specific differences other than where the files live?
  • Agreed - had intended to tackle this if you were open to the change.
  • I'd also thought about this - but wasn't sure how much it should cover. It'd be reasonably easy to add in as a bash script under misc (as it'd be something that becomes obsolete in a few months). Initial list of stuff that comes to mind:
    • move config, prompt and menu.hjson into the right place
    • move themes that aren't luciano_blocktronics
    • move mods in directories to new mods location
    • anything else? I'd expect that most stuff would be covered by a git pull...

@NuSkooler
Copy link
Owner

Going to merge now - looking great.

  • Thinking about oputil.js upgrade: I think for now, there are such limited Enig users, some notes in UPGRADE.md will do.
  • We can get the @systemModule stuff cleaned up after merge

@NuSkooler NuSkooler merged commit 4e1bbe4 into NuSkooler:0.0.8-alpha Nov 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants