@sheinbergon, would you mind reviewing this (with #263 as context)? Have I missed anything else?

Sure. Will do it later on today

IMO, It just doesn't feel like a proper use case (especialy given what what _inject_marker and _noinject_marker aim to solve)

Random driveby comment: when I still worked on this library I actually planned to get rid of the inject decorator and noninjectable/NoInject too (not useful as they only solve problems with the inject decorator); only the Inject type would be used to declare injectable parameters in that situation.

This could simplify some parts of the implementation but also comes with some drawbacks.

We should re-activate coverage measurement (I can't do it as a mainatiner, I believe)

You're right. I just sent @davidparsson an invitation to the GH organization (not just this repository), Coveralls needs to be granted access to the organization and then I think the repository needs to be activated in the Coveralls settings. Let me know if more information is needed about any of this.

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.29%. Comparing base (9e68690) to head (eb338b8).
⚠️ Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master     #279      +/-   ##
==========================================
+ Coverage   95.23%   95.29%   +0.05%     
==========================================
  Files           1        1              
  Lines         567      574       +7     
  Branches       96       98       +2     
==========================================
+ Hits          540      547       +7     
  Misses         20       20              
  Partials        7        7              

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

IMO, It just doesn't feel like a proper use case (especialy given what what _inject_marker and _noinject_marker aim to solve)

Random driveby comment: when I still worked on this library I actually planned to get rid of the inject decorator and noninjectable/NoInject too (not useful as they only solve problems with the inject decorator); only the Inject type would be used to declare injectable parameters in that situation.

This could simplify some parts of the implementation but also comes with some drawbacks.

There might very well be internal benefits with this, but it would be a painful migration in large projects. I'm using this in a codebase with 1500+ @inject decorators.