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

Plugin dependencies #12

Open
4 tasks
Kwpolska opened this issue Oct 11, 2013 · 8 comments
Open
4 tasks

Plugin dependencies #12

Kwpolska opened this issue Oct 11, 2013 · 8 comments
Assignees

Comments

@Kwpolska
Copy link
Member

  • Find a sane way to implement it (a third file does not make much sense)
  • Make it nicely visible in the web app
  • Have the install_plugin option install the plugins
  • Make sure we do not break much by implementing it
@ghost ghost assigned Kwpolska Oct 11, 2013
@ralsina
Copy link
Member

ralsina commented Oct 11, 2013

You mean plugins depending on other plugins? I think a metadata field in the .plugin file is enough

@Kwpolska
Copy link
Member Author

How would that work?

We could:

  1. Requirements = a,b,c (ignoring spaces)

  2. Requirements = a;b;c (ignoring spaces)

  3. Requirements = [a,b,c] (ignoring spaces)

  4. (wouldn’t configparser shit itself?)

    [Nikola]
    Requirement = a
    Requirement = b
    Requirement = c
    [Requirements]
    Requirement = a
    Requirement = b
    Requirement = c

    6. (what about more specific ranges? Or should we ignore the value altogether?)

    [Requirements]
    a = 0.1.0
    b = 0.2.0
    c = 0.5.0

Or maybe, in requirements.txt:

nikola.plugins.a
nikola.plugins.b
nikola.plugins.c

@ralsina
Copy link
Member

ralsina commented Oct 11, 2013

Assuming the dependency names are just strings, we can always use "['foo','bar']" which can be created using json.dumps but it should not be necessary, I like your version 6

@damianavila
Copy link
Member

Yep, I think version 6 is more clean...

@Kwpolska
Copy link
Member Author

So, let’s actually trim out all of that nonsense and leave in two.

  1. *.plugin
[Requirements]
a = 0.1.0
b = 0.2.0
c = 0.5.0
  • Advantages:
    • separated from python requirements
  • Disadvantages:
    • it’s hard to create a format that would encompass all version requirements
    • we (plugins.getnikola.com) provide only one version of a plugin anyways, making versions here a waste of time and space
    • and we do not have anything else to put after the = sign, something we have to do
  1. requirements.txt
nikola.plugins.a
nikola.plugins.b
  • Advantages:
    • unambiguous
    • plugins are python but are not in the pypi — we can filter the file for installation with pip
    • if we ever implement multiple versions, it can be added in the usual syntax at any given moment
  • Disadvantages:
    • mixed with python requirements

@Kwpolska
Copy link
Member Author

any thoughts, ideas, or such?

@ralsina
Copy link
Member

ralsina commented Oct 11, 2013

I'm ok with both

@damianavila
Copy link
Member

Re-thinking, I am more inclined to the second one version...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants