search

pipalacademy / riyaz

A light-weight, self-hostable learning platform.
MIT License
2 stars 0 forks source link

Integrate Feather with Riyaz #9

Closed nikochiko closed 2 years ago

anandology commented 2 years ago

Rather than integrating riyaz with feather, would it be possible to think about an extension architecture and write a feather extension for riyaz? That way, the feather integration will not be part of the riyaz core. And it would allow us to support more such extensions in future.

On Tue, Aug 16, 2022 at 11:33 PM Kaustubh Maske Patil < @.***> wrote:

— Reply to this email directly, view it on GitHub https://github.com/pipalacademy/riyaz/issues/9, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAB3EJ37SYCFIZST6W5TBLVZPJVPANCNFSM56WXQ2DA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

anandology commented 2 years ago

This depends on #23. That is well scoped for implementing the first version. Once it is ready, it should be possible to integrate the work we have done for mkdocs-feather into this.

@nikochiko what do you think?

nikochiko commented 2 years ago

23 is done! but there are some more decisions that need to be made for getting this through.

I have some thoughts on each:

  1. Repository? -> we should have a new repository, so that we can bundle assets along with the code without worrying about size.
  2. Assets? -> Assets should go with the code so that they remain accessible to anyone who can access the plugin code. We should structure them like we did with mkdocs-feather (symlink vendor/ from assets/)
  3. Hosting assets -> A good way to do this would be to use the assets management we built into riyaz, save the files as assets for extension and then let riyaz serve them. But this doesn't decouple riyaz core and plugins properly.
  4. Configuration -> Plugin configuration should be taken from riyaz.config. Config should be a dictionary object with a sensible name (like, riyaz.config.feather or riyaz.config.feather_config). If environment variables are at all being read, they too should have a prefix that is (likely to be) unique to the plugin.
anandology commented 2 years ago

Same repository.

Bundle assets with riyaz for now. We'll see how to manage assets for each plugin seperately later.

On Mon, Aug 29, 2022, 4:07 PM Kaustubh Maske Patil @.***> wrote:

23 https://github.com/pipalacademy/riyaz/issues/23 is done! but there

are some more decisions that need to be made for getting this through.

  • Do we make a new repository for this?
  • Do we ship assets along with the code?
  • Where do we host the assets?
  • Where does the configuration for this live? (e.g. the feather server URL)

I have some thoughts on each:

  1. Repository? -> we should have a new repository, so that we can bundle assets along with the code without worrying about size.
  2. Assets? -> Assets should go with the code so that they remain accessible to anyone who can access the plugin code. We should structure them like we did with mkdocs-feather (symlink vendor/ from assets/)
  3. Hosting assets -> A good way to do this would be to use the assets management we built into riyaz, save the files as assets for extension and then let riyaz serve them. But this doesn't decouple riyaz core and plugins properly.
  4. Configuration -> Plugin configuration should be taken from riyaz.config. Config should be a dictionary object with a sensible name (like, riyaz.config.feather or riyaz.config.feather_config). If environment variables are at all being read, they too should have a prefix that is (likely to be) unique to the plugin.

— Reply to this email directly, view it on GitHub https://github.com/pipalacademy/riyaz/issues/9#issuecomment-1230107309, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAB3EKSRRXXHYUFWIFGXZLV3SHHLANCNFSM56WXQ2DA . You are receiving this because you commented.Message ID: @.***>