Externalize themes in independant packages.

[flowgunso]

In the official .js implementation, any theme installed system-wide that is named jsonresume-theme-.* can be used. Following that behavior could be favorable. It shouldn't be very hard but could ease the management of this project in different ways:

• Each official default theme you already wrote in resume_json/templates/ would have its own repository. The cli and themes would be autonomous. But, having them in a requirements.txt file in the cli would still make them available by default.
• Original creators of themes may be interested in using the Jinja2 template engine instead of the obsolete Handlebars one in .js.
• Other people may be interested in contributing their own theme, which could then be used easily.

That kinda goes against what I wrote #1 and #2, but meh.

The implementation in the cli would rely on using several PackageLoader. But that also means creating new repository for existing themes.

https://github.com/jsonresume/resume-cli/blob/c5d057eba6dda1485d6a207a0bc12935806de414/lib/main.js#L17-L26
That's essentially the official implementation.

[moshe742]

I agree that it will be a good idea to implement a way to include other templates by a name convention (or other ways, such as signals or whatever).

On the other hand, I think we should keep at least one theme with the package, that way you don't have to install other themes just to work with the system and it makes it simpler to just check if it works for your use case.

If we implement the theme included in the package the same way we want the theme creators implement their themes it will have even a better way to make sure the theme discovery and theme creation is done on our side the right way, since we use the system as intended by us. Thus, making sure not only the code is working as intended (which should be covered by tests, so might be redundant), but also the documentation and everything else.

So, I suggest that we will keep at least one of the themes in the package, but implement it in the way you suggest and include tests to make sure nothing breaks in the future without us knowing about it beforehand.
The other themes that we decide to move outside of the package we will create a repository for each or all, not sure yet and they will be tested too with the system when relevant (and will be maintained by us).

That way we can benefit from what you are talking about, but with less packages needed to install and hopefully easier maintenance.

Either way, I don't think that this goes against #2 since both features serve different purposes, the flag theme-dir is useful when one wants to create a theme to publish or use her own "home" made theme/template, while the feature your are talking about here is for after publishing the theme, so those are two different use cases :)
What do you think?

[flowgunso]

the flag theme-dir is useful when one wants to create a theme to publish or use her own "home" made theme/template

Yes, that's true.

I suggest that we will keep at least one of the themes in the package

Yes, OK. This is going gradual process anyway, splitting into several repository and setting up the dependencies will take some time.

How about?

1. We pick one theme and make it autonomous with it's own repository and make it available through PyPi.
2. Then, start implementing it into the cli, as a package dependency, but not touching the rest of the templates import systems.

[moshe742]

1 sounds good, but not sure what you mean by 2.
After we remove the theme from the package shouldn't we work on importing it automatically if it's on the system and use it when the user want it?
Or you say that we can work on all the other stuff for this but not the import itself until everything else is done?
I guess that the import will not be an easy task either way, so it's logical to postpone it, but we need to know at least if it's on the roadmap for the project

[flowgunso]

After we remove the theme from the package shouldn't we work on importing it automatically if it's on the system and use it when the user want it?

That's what I meant with 2., yes.

[moshe742]

OK, sounds good to me

[flowgunso]

I've just forked jsonresume-theme-stackoverflow to work on 1.:

1. We pick one theme and make it autonomous with it's own repository and make it available through PyPi.