Explicit part dependencies

[Jim Fulton]

I've drafted a topic on implicit parts:

  https://github.com/buildout/buildout/blob/implicit-parts/doc/topics/implicit-parts.rst

But I don't like the example.  A better example would be a ``server`` part that generated a zdaemon runner that depended on a software (e.g. zc.wsgirunner + app) part that build the thing to be run and a config part that generates its config:

[buildout]

develop = .

parts = server

[server]

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

[config]

recipe = zc.recipe.deployment:configuration

text = ...

[app]

recipe = zc.recipe.egg

eggs = zc.wsgi-runner

       myapplication

But zc.recipe.egg doesn't have any data that's useful and there's no explicit way to say that one part depends on another.  I'm thinking there should be some way to declare required parts without referring to part options.  If buildout was brand new, I'd be tempted to use a ``parts`` option in parts, but I don't think that's an option now.

I could do something with unusual option names, as I did with macros.

[server]

& = app config 

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

Or maybe:

[server]

<requires> = app config 

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

Hm, I kinda like that last one. Maybe say <name> is reserved for buildout.  We could make <= a shorthand for <extends> =. 

Or maybe something in the section header:

[server :requires app config] 

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

(Somehow, I don't like that.  In fact, I might rather do conditional sections as:

  [extensions]

  ?= windows

  ext = .bat

  )

Or make-like

[server]: app config 

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

or

[server]

: app config 

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

or ...

Jim

P.S. 

• This illustrates why I like writing real documentation before implementing features.
• I'm happy to use some other template recipe if there's a better one that works with Python 2 and 3. :)  I just use what I know. 
  

--

Jim Fulton
http://jimfulton.info

[Benji York]

On Thu, Mar 2, 2017 at 6:34 PM, Jim Fulton <j...@jimfulton.info> wrote:

[server]

<requires> = app config 

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

Hm, I kinda like that last one. Maybe say <name> is reserved for buildout.

That seems reasonable.  It is a bit noisy, though.  Improvisation follows.

Perhaps a separator with buildout options above and recipe options below, like so

[server]

requires = app config

--

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

Using only a leading character would reduce the noise.

 

[server]

> requires = app config

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

Is it too soon to use unicode characters?

[server]

requires →app config

recipe = zc.zdeamonrecipe

program = ${buildout:bin-directory}/run-wsgi ${config:location}

I typed the above arrow character almost as easily as an ASCII character because I do so often.  YMMV

 

(Somehow, I don't like that.  In fact, I might rather do conditional sections as:

  [extensions]

  ?= windows

  ext = .bat

  )

English speakers often use parenthesis as pseudo conditionals, which lead me to this thought:

[extensions (windows)]

ext = .bat

 

P.S. 

• This illustrates why I like writing real documentation before implementing features.

Indeed!  This is a lesson I keep relearning and repeating to others.

--

Benji York

[Maurits van Rees]

Since we have `<=` to inherit from a part, we could use `<` to depend on that part.

[Jim Fulton]

On Fri, Mar 3, 2017 at 6:05 PM, Maurits van Rees <mau...@vanrees.org> wrote:

Since we have `<=` to inherit from a part, we could use `<` to depend on that part.

Except that <= is really <. http://docs.buildout.org/en/latest/topics/variables-extending-and-substitutions.html#extending-sections-using-macros

I was thinking of <-, which would require changes to the parser.

I was also thinking of allowing ← as an alias for <- and ⇐ as an alias for <= :). This could be done with pre-parsing hacks.

Oh oh wait, we want ⇒ as an alias for => which is mathematical implication. Definitely requires pre-processor hacks. :)

[server]

=> app config

I think that's it. 

Jim

[Jim Fulton]

Note that this would get transformed by the preprocessor to:

[server]

<part-dependencies> = app config

and then the <part-dependencies> option would get special handling as the existing < option does.

I'm decided. Any objections? (Or my second favorite Zope error: no argument expected :))

Jim

[Jim Fulton]

On Fri, Mar 3, 2017 at 6:49 PM, Jim Fulton <j...@jimfulton.info> wrote:

...

I was also thinking of allowing ← as an alias for <- and ⇐ as an alias for <= :). This could be done with pre-parsing hacks.

Oh oh wait, we want ⇒ as an alias for => which is mathematical implication. Definitely requires pre-processor hacks. :)

[server]

=> app config

I think that's it. 

Note that this would get transformed by the preprocessor to:

[server]

<part-dependencies> = app config

and then the <part-dependencies> option would get special handling as the existing < option does.

I'm decided. Any objections? (Or my second favorite Zope error: no argument expected :))

I'm  bailing on unicode (at least for now), as it opens a can of worms wrt encoding. 

Jim

[Jim Fulton]

https://github.com/buildout/buildout/pull/367

Jim