-
Notifications
You must be signed in to change notification settings - Fork 3
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
Externalize themes in independant packages. #4
Comments
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. 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 :) |
Yes, that's true.
Yes, OK. This is going gradual process anyway, splitting into several repository and setting up the dependencies will take some time. How about?
|
1 sounds good, but not sure what you mean by 2. |
That's what I meant with 2., yes. |
OK, sounds good to me |
I've just forked jsonresume-theme-stackoverflow to work on 1.:
|
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:requirements.txt
file in the cli would still make them available by default.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.
The text was updated successfully, but these errors were encountered: