juergbi commented on PR #2119:
URL: https://github.com/apache/buildstream/pull/2119#issuecomment-4412284906

   > I'm not very knowledgeable about the loading process, so correct me if my 
understanding is wrong. The usual solution for this kind of things that we want 
to use at load time is to load them early, so that we can have them already 
when loading junctions. But for this particular case, we want to avoid that to 
allow these source provenance attributes to be loaded using an include?
   
   Yes. Unfortunately, the combination of includes from project.conf and 
junctions makes the whole loading process very tricky.
   
   I would also have preferred to do it without a callback. However, the 
junction/include combination already now relies on not loading pass 2 of 
projects earlier than necessary. The callback is the simplest approach I could 
think of that works with the current architecture/constraints (and hopefully 
not rendering a currently valid project invalid). Assuming we do need to 
support include files for source provenance.
   
   > Conceptually, I think this check needs to happen at plugin configure time 
rather than at plugin load time. Maybe we can do that instead by having Source 
override Plugin._configure() to make this check?
   
   `Source._configure()` is called by the constructor, so I don't see a 
meaningful difference there. Or am I misunderstanding your suggestion?
   
   The basic issue is that sources of junctions need to be fully functional 
(fetch) even if the second loading pass of the project is not done yet. Based 
on that, I don't see a possibility to move the check to some other already 
existing method.
   
   An alternative to the callback could be to add e.g. 
`Element._second_pass_done()`, which is called unconditionally by the project, 
instead of invoking a registered callback. However, that currently sounds worse 
to me.
   
   It's certainly possible that I'm overlooking a better option, of course. Can 
you think of anything else?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to