why is the compat section of this package so restrictive?

[ExpandingMan]

The compat section of the Project.toml for this package is very restrictive, and is wreaking havoc on my environment. Are there specific reasons for all these restrictions (the reason for my skepticism is that this package is largely a simple HTTP wrapper)? If not, I'd beg that we can remove them. Unnecessary compat restrictions are really harmful as they cause packages to be downgraded unnecessarily, if more packages were so restrictive, there'd be a high risk of getting unsatisfiable requirements.

[mattBrzezinski]

I added dependency versions in the compat section as the JuliaRegistrator zeptodoctor bot requires them for automerge:

JuliaRegistries/General#4846 (comment)

The versions in the Project.toml were the only ones I was able to get the project building with successfully. If this is a blocking issue, and problematic for lots of people I'm fine with removing the changes and having JuliaRegistrator be a manual process.

Do others have any thoughts?

[ExpandingMan]

The versions in the Project.toml were the only ones I was able to get the project building with successfully.

I've just tried building it with the compat section removed, and it definitely builds. The question is, do tests pass? (unfortunately it's very hard to test this package). Again, my skepticism here comes from the nature of this package. I could definitely at least imagine there being cases in which one needed to restrict AWSCore, HTTP or EzXML, but there is an awful lot of stuff being restricted here by this very, very minimal package. I haven't been able to completely disentagle why it downgrades so much for me.

[mattBrzezinski]

I've just tried building it with the compat section removed, and it definitely builds. The question is, do tests pass? (unfortunately it's very hard to test this package).

I don't see why they wouldn't unless there's an underlying issue with a dependency. Before the changes in #56 I didn't run into any issues with testing.

Again, my skepticism here comes from the nature of this package. I could definitely at least imagine there being cases in which one needed to restrict AWSCore, HTTP or EzXML, but there is an awful lot of stuff being restricted here by this very, very minimal package.

It seems that zeptodoctor looks at non-base deps and forces a restriction on them in the compat section for auto-merge.

@omus @iamed2 @rofinn any thoughts on this?

[KristofferC]

The compat section in this file is following best practices and is not overly restrictive.

[oxinabox]

I was talking to @mattBrzezinski when he made the PR to add Compat versions.
He even went back, and carefully tested each version of each package that has multiple versions listed.
To make sure they worked.

He did the good thing.
Rather than just test on the latest version of everything that he was using and locking compat to that.

If there is a particular package compat restriction you would like to see relaxed.
Then open an issue called:
"Can the restriction on HTTP be relaxed to 0.7,0.8"
Or what ever the restriction is that is hurting.

The overall practice here is the correct one.

[ExpandingMan]

I'm not accusing anyone of anything wrong here, but for a package this simple to cause so many downgrades and nobody knows exactly why does not bode well at all for a future in which all packages have these restrictions. When I have time I will dig through this and figure out what the problem is.

[mattBrzezinski]

but for a package this simple to cause so many downgrades and nobody knows exactly why

Could you post the packages and their versions in your environment? I can help try and root cause the issue in some free time.

does not bode well at all for a future in which all packages have these restrictions

It's definitely possible to end up in this state, and I can see the concern. I don't think this is the package to have this discussion in, but I'd raise your concerns with it in either the Julia Slack / Discourse / Git Issue page(s).

[ExpandingMan]

Ok, I've looked into this a bit more. It turns out that the most egregious problems were not caused by this package (I still don't know where they are coming from), but one thing from this package that is likely causing issues is the bound on MbedTLS. This package had an 0.7 release way back in June, is there some reason it is capped to 0.6 in AWSS3.jl?

[mattBrzezinski]

Ok, I've looked into this a bit more. It turns out that the most egregious problems were not caused by this package (I still don't know where they are coming from), but one thing from this package that is likely causing issues is the bound on MbedTLS. This package had an 0.7 release way back in June, is there some reason it is capped to 0.6 in AWSS3.jl?

AWSCore.jl currently restricts [email protected], which prevents this package from upgrading to [email protected].

https://github.com/JuliaCloud/AWSCore.jl/blob/v0.6.4/Project.toml#L26

[oxinabox]

AFAICT this package doesn't actually directly load MbedTLS.jl ?
So we can probably just drop it from the dependencies entirely?

MbedTLS.jl releases tend to need to be synconized against Julia releases for reasons I don't understand entirely,b but that i think boil down to Julia also including the MbedTLS shared library and that gets mad if you link against common versions. So I bet that once can be relaxed a bunch?

[mattBrzezinski]

AFAICT this package doesn't actually directly load MbedTLS.jl ?
So we can probably just drop it from the dependencies entirely?

MbedTLS is being used here:

https://github.com/JuliaCloud/AWSS3.jl/blob/master/src/AWSS3.jl#L790

[mattBrzezinski]

In-case anyone wants to see a continuation of this discussion

https://discourse.julialang.org/t/please-be-mindful-of-version-bounds-and-semantic-versioning-when-tagging-your-packages/30708

Thanks @ExpandingMan

[mattBrzezinski]

AWSCore.jl has a CR going through for including [email protected], link.

I'll create a CR to bump the version here as well. However it should be noted that if you're using [email protected], you will be locked to Julia v1.2.X.

[oxinabox]

Why does this load MbedTLS in the middle of the file?

AWSS3.jl/src/AWSS3.jl

Line 742 in d8697e4

using MbedTLS

:-(

[omus]

I'll close this issue as I'm pretty certain there isn't anything actionable left here. As of AWSCore v0.6.5 there is now support for MbedTLS v0.7 (requires Julia 1.2). That change should take care of the downgrades that were observed.