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

Extend Partial Resolution #76

Open
iwanfrancis opened this issue Aug 7, 2020 · 7 comments
Open

Extend Partial Resolution #76

iwanfrancis opened this issue Aug 7, 2020 · 7 comments

Comments

@iwanfrancis
Copy link

iwanfrancis commented Aug 7, 2020

I may have be missing something which is already possible, so apologies if this is case.

I'd like to be able to have a reference to a specific part of the 'parent' file become an internal reference when the 'child' file is resolved.

Minimal Example Spec

root/parent.yaml

Child: 
    $ref: './subfolder/child.yaml'
Parent:
    ...

root/subfolder/child.yaml

something:
    $ref: '../parent.yaml#/Parent

Would resolve to:
compiled.yaml

Child: 
    something: 
        $ref '#/Parent'
Parent: 
    ...

Actual Behaviour

I've tried to produce this effect with the partial resolution option, but have not been able to get it to work. Applying only RESOLVE_FILES will result in a crash, as the references isn't actually an internal reference. Running without RESOLVE_FILES will fully resolve the reference.

@jfinkhaeuser

@jfinkhaeuser
Copy link
Collaborator

Sorry I did not immediately respond! Github emails sometimes seem to get lost for me.

This isn't something that's currently supported, but I do like the idea. Let me have a think about it. I have a feeling it's actually going to be easy...

The problem with a lot of these requests people have is that they require context that the resolver doesn't currently have. I think though in this case everything is there to make it work.

@jfinkhaeuser
Copy link
Collaborator

I took a look at #77 first, because it seemed easier, and I have an approach to adding that functionality. It's eerily similar, but not the same.

The solution I proposed there would require you not to set the RESOLVE_INTERNAL flag (and use a handler of sorts) - but I wonder, would that be too wide-ranging for you? Would you want references from parent.yml to #/foo/bar to resolve, or should they also stay untouched? If the latter, then I think a similar approach to #77 would work.

@iwanfrancis
Copy link
Author

Apologies, I've been away from my work computer for the last week and didn't see this.

I think it would be fine for internal references within a parent to remain untouched, yes

@jfinkhaeuser
Copy link
Collaborator

Ok, thank you - no need to apologize, I also have a ton of other things on my mind. The break was good :) I'll get back to this as soon as I can.

@jfinkhaeuser
Copy link
Collaborator

This will take me a while longer, mostly due to time constraints. The issue is the recursive nature of your references here. As it currently stands, the resolver for the parent file will start a resolver for the child file, which will look up in the parent file how to resolve a reference. The key point here is the parent file - not the current parent resolver.

It would need some kind of back channel to the parent resolver to achieve this kind of thing. Which, to be fair, would be a powerful feature, but it's not really something I'll have much time for in the near future.

@Glutexo
Copy link
Collaborator

Glutexo commented May 10, 2021

This too, just as #77 will be resolved by the new Translating Parser. It does not support all the configuration options of the ResolvingParser, but the a viable prototype lives now in Glutexo/prance-translating-parser and I’ll create pull request to add it to the upstream.

@Glutexo
Copy link
Collaborator

Glutexo commented May 10, 2021

This test should cover this issue. Please challenge if you feel there is a need for more tests.

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