Codecov Report

Attention: Patch coverage is 66.66667% with 3 lines in your changes are missing coverage. Please review.

Project coverage is 71.70%. Comparing base (3eb14d5) to head (d9dc971).
Report is 2 commits behind head on main.

@@            Coverage Diff             @@
##             main    #2618      +/-   ##
==========================================
- Coverage   71.71%   71.70%   -0.02%     
==========================================
  Files         365      365              
  Lines       23657    23645      -12     
  Branches     3855     3855              
==========================================
- Hits        16966    16954      -12     
  Misses       5569     5569              
  Partials     1122     1122              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I think this is much nicer than just using a regular partial. These are my only concerns:

1. Versus rewriting the function definition in each case, a downside will still be that the docs for the cell are not tailored to each function. Of course, this is no better or worse than a partial, but still results in something less polished than if you were to write a function wrapper for each case (or only maintain one function for the PDK with a string arg for each case). I suppose you could get around this though by providing a doc argument or something like that.
2. I'm not sure it's best to conflate all this into cell directly vs creating a separate function (i.e. partial_cell) for this purpose. I'm concerned of edge cases and user confusion if we let cell become overly complicated... I suppose it's ok though and might be more difficult to implement otherwise. Thoughts?

derived_cell?

That's a good name

the issue is that it would require maintaining 2 cell decorators, so maybe keeping one only makes things easier

@sebastian-goeldi

maybe this is too hacky and shoulnd't be merged, as it won't be compatible with the future kfactory backend,

i'll mark it as draft

@nikosavola