Revert "add Printf support (#201)"

[bvdmitri]

This reverts commit 450defe.

Fixes #206

This change is pretty disruptive and makes many packages fail in 1.10 due to circular dependencies. This is oke to revert until a better solution is in place.

[bvdmitri]

Another reason to revert this code is that it depends on private internals of Printf which are not meant to be extended

julia> using Printf

help?> Printf.fmt
  │ Warning
  │
  │  The following bindings may be internal; they may change or be
  │  removed in future versions:
  │
  │    •  Printf.fmt

  No documentation found for private symbol.

  Printf.fmt is a Function.

help?> Printf.plength
  │ Warning
  │
  │  The following bindings may be internal; they may change or be
  │  removed in future versions:
  │
  │    •  Printf.plength

  No documentation found for private symbol.

  Printf.plength is a Function.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.12%. Comparing base (13c76e1) to head (381bbb3).
⚠️ Report is 24 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #207      +/-   ##
==========================================
- Coverage   99.11%   98.12%   -0.99%     
==========================================
  Files           6        6              
  Lines         225      267      +42     
==========================================
+ Hits          223      262      +39     
- Misses          2        5       +3     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aplavin]

Agree with the revert of course, as stated in the issue. Just note that

Another reason to revert this code is that it depends on private internals

is not the common practice in Julia. A lot of very popular packages depend on internals or overload them. Arguably, the majority?

[dlfivefifty]

A lot of very popular packages depend on internals or overload them. Arguably, the majority?

Mine definitely do! Possibly to an extreme extent.

I think the old-school OOP strict private/public interface is not as important as it used to be because one has the possibility of downstream tests to pick up packages breaking due to changed internals.

[bvdmitri]

Bump, can we merge this and tag a new release?

[dlfivefifty]

if you want this tagged can you bump the version?

[aplavin]

The plan is to make it v0.8, right?

[dlfivefifty]

No make it a patch version: it’s more like a bug fix

[aplavin]

It's unambiguous removal of existing functionality in a patch version then...

[dlfivefifty]

As we already discussed: in this case we are fixing a problem so it makes sense to bend the rules of semvar.

Though the alternative is to yank the previous tag. So if you are not happy with a patch version why don't you just make a PR Into registry deleting the tag?

[bvdmitri]

I bumped the version to 0.7.13. This PR doesn't remove any functionality of the package, only some custom pretty-printing when other package happens to be loaded. The version 0.7.12 doesn't have any new functionality because this version simply doesn't work as intended and breaks workflows of many people that don't even use Printf. There is no good reason to make it 0.8 and leave 0.7.* in a broken state forever.

[bvdmitri]

@aplavin you're welcome to re-implement the Printf functionality in a separate PR in a way that works nicely on Julia LTS and above. Until then, I don't think its useful to argue and bringning some semver behaviour where many people experience problems with their workflows. You had 5 days to make a new PR which you think would be better than this one, something has to be done and if we don't have anything better than this PR lets merge it and you will have more time thinking of a better solution and restores the behaviour that you want

[dlfivefifty]

I doubt the nightly failures are related. Let's merge and tag?

[aplavin]

This PR doesn't remove any functionality of the package, only some custom pretty-printing when other package happens to be loaded.

False: the removed tests work on the previous version, but error (don't just return a slightly different "pretty printing") on the new one.
You logic seems to be that package extensions aren't covered by semver. That's... a pretty unusual pov to be honest.

The version 0.7.12 doesn't have any new functionality because this version simply doesn't work as intended and breaks workflows of many people that don't even use Printf.

The version 0.7.12 clearly has new functionality, as evidenced by the tests you removed: they work on 0.7.12, but error on the new one.
The fact that the new functionality happens to uncover a less-known bug in Julia doesn't mean "doesn't have any new functionality", that's very twisted logic.

[aplavin]

@aplavin you're welcome to re-implement the Printf functionality in a separate PR in a way that works nicely on Julia LTS and above. Until then, I don't think its useful to argue and bringning some semver behaviour where many people experience problems with their workflows. You had 5 days to make a new PR which you think would be better than this one, something has to be done and if we don't have anything better than this PR lets merge it and you will have more time thinking of a better solution and restores the behaviour that you want

Me (same as many others) are not affected by this Julia bug at all, and naturally had little motivation to do this.
Note that the "default" assumption in Julia is that packages follow the versioning pattern of packages keeping backwards compatibility between patch versions.

But anyway, the decision on what to release is always up to maintainers – I'm just giving my opinion here.