Skip to content

[ENH]: Introduce junifer.api.generate_yaml#498

Open
synchon wants to merge 7 commits into
mainfrom
feat/generate-yaml-api
Open

[ENH]: Introduce junifer.api.generate_yaml#498
synchon wants to merge 7 commits into
mainfrom
feat/generate-yaml-api

Conversation

@synchon

@synchon synchon commented May 29, 2026

Copy link
Copy Markdown
Member
  • description of feature/fix
  • tests added/passed
  • add an entry for the latest changes

This PR adds generate_yaml under api to generate feature YAML from metadata. Its primary use-case is in julio's feature addition to registry.

@codecov

codecov Bot commented May 29, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (32666e1) to head (7e49b70).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff            @@
##              main      #498   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            1         1           
  Lines            1         1           
=========================================
  Hits             1         1           
Flag Coverage Δ
docs 100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@fraimondo

Copy link
Copy Markdown
Contributor

I have the impression that this way (dump_exclude) adds a lot of maintenance work: if something changes in the superclass (new internal variable), we need to go and update every subclass, including non-junifer ones.

Can't we just look at what fields are defined in the class (not the superclass) and just pass those ones to the constructor?

@synchon

synchon commented Jun 8, 2026

Copy link
Copy Markdown
Member Author

I have the impression that this way (dump_exclude) adds a lot of maintenance work: if something changes in the superclass (new internal variable), we need to go and update every subclass, including non-junifer ones.

That's a fair argument and I see your point.

Can't we just look at what fields are defined in the class (not the superclass) and just pass those ones to the constructor?

Not with how I understand the thing works. A model's fields consist of its own fields and superclass' fields (if it has one). So apart from defining what to exclude (or include), I don't see other way. I'll push some updates to make it better.

@synchon synchon force-pushed the feat/generate-yaml-api branch from a5c4e20 to 7e49b70 Compare June 15, 2026 09:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants