Compile step of default plugins into geometry about geometry HOT 8 CLOSED

I'm not really sure about this feature/change as this may impose more tools/processes for new comers in order to submit a PR and may make PR/review/merging a bit hard. At least it'll add a new step in the development process.

I'm thinking about the following setup:

• Add src/main.zsh with current geometry.zsh
• geometry.zsh will become the result of cating lib/*, plugins/* and src/*

We'll probably need a Makefile (or similar build tooling) for this.

So, basically we're adding a new step to the development process:

1- Make code change
2- Build geometry with make command
3- Test change

When handling PR we'll need to request for the submitter to build geometry before merging their changes (or do it ourselves).

Is it worth adding this complexity just to keep geometry a single file? @frmendes Any thoughts?

from geometry.

Well, it will definitely make it harder to develop, but there could be a few alternatives.

Setting a GEOMETRY_ENV environment variable to production by default and only compiling and sourcing the compiled file in that case. If set to development, it sources just like it is.

Compiling everything has the advantage of letting us track versions as well. The version on master doesn't necessarily have to be the compiled version. We would only compile when bumping up. That should leave that logic out of the development process and the PR creation.

What bothers me the most is that this would mean users would have an extra-step before setting up geometry, right? It's not just "plug and play" anymore.

from geometry.

Yeah, that's a good approach. By default geometry will run by sourcing lib and plugins, when compiled there is no need for sourcing. No extra steps required for developers except for the one involved in releasing the changes.

Maybe it's a good time to implement release versions.

The main advantage for end users is that they could install geometry just by wget / curl and sourcing it (ie, no need for git or downloading the zip and unzipping it).

from geometry.

We would be dropping zplug, antigen, etc plug and play support wouldn't we? I'm fine with that, since it's just sourcing the plugin on .zshrc.

from geometry.

Not at all as for end users it'll be completely transparent. At the end of the day geometry.zsh will look the same for antigen, zplug, end users etc. regardless of the install method.

from geometry.

I'm really fine with that. Adding release versions should be good now as the theme has grown a bit by now. After #51 gets resolved it's more of a prompt configuration wrapper with cool defaults than a simple theme. I'm definitely down for that.

So, I guess it goes like this:

• Add an environment variable for development or production.
• Have geometry source whatever it needs depending on the environment.
• Add a bin/compile file that compiles everything into a build/geometry.zsh and bumps the version.
• Add a CONTRIBUTING.md and start tagging versions.

Did I forget anything?

from geometry.

Not really sure about auto bumping versions but I'll go ahead and start with the compile steps and prod/dev logic.

from geometry.

Forgot about this one. Compilation will not be implemented. Closing.

from geometry.