Closed matthewfeickert closed 3 years ago
@kratsg if you can confirm that things are working for you I'll release v0.3.1
after this PR as I forgot to bump the minimum required panda-client
for v0.3.0
.
confirmed
I agree with bumping the required version of the panda client: I have no idea what would work with version 1.0 (probably nothing).
Still, give that @kratsg specifically added a workaround so we can use 1.4.81 we should probably say we support it right? Bumping beyond that is telling users / admins that a newer version is required whereas what we want to say is that the older version is deprecated.
Still, give that @kratsg specifically added a workaround so we can use 1.4.81 we should probably say we support it right? Bumping beyond that is telling users / admins that a newer version is required whereas what we want to say is that the older version is deprecated.
@dguest Given the way that things work, anything in setup.cfg
like
only comes into play if you are pip
installing pandamonium
. If you are doing the "oldschool way" then setup.cfg
never even gets used. Because of this, we would want to have backwards compatibility on pandas-client
APIs until we're quite sure that all ATLAS cites show panda 1.4.82
or later following lsetup panda
.
But if you are installing from PyPI then it is better to make it clear what are the lower bound of your dependencies and now we have a clear lower bound on using the supported APIs of panda-client
v1.4.82
. So this PR is only going to affect users like me that pip
install pandamonium
on their local machines and users like @kratsg that are pip
installing it in Docker images.
If we actually want to have a deprecation warning then we should probably raise and then catch a DeprecationWarning
exception.
Thanks for confirming that we only use setup.cfg
for pip installs, but my point was more that if someone has a reason to use panda-client 1.4.81 that's fine (even with the pip install). Of course they should probably take the newer one, but I think taking the newest tag is the default behavior for pip anyway, right? So unless I'm mistaken, setting the requirement to 1.4.82 is a more forceful way to update people but not the only way: they will pull the more recent version by default.
That being said, I don't really see a problem with either approach, I'll merge this if that's what you think is best.
Thanks for confirming that we only use
setup.cfg
for pip installs, but my point was more that if someone has a reason to use panda-client 1.4.81 that's fine (even with the pip install). Of course they should probably take the newer one, but I think taking the newest tag is the default behavior for pip anyway, right?
Correct, pip
will figure out the dependency lower (and upper) bounds and then install the latest release that passes them.
So unless I'm mistaken, setting the requirement to 1.4.82 is a more forceful way to update people but not the only way: they will pull the more recent version by default.
I view it as giving the users an assurance: This library is known to safely work with this lower bound of this dependency. This can change in the future as needed, but when you regularly test and update your lower bounds then you know that the releases that people are getting on PyPI will work when in the worst case scenario they or pip
is required to fall back to this lowest supported release.
In general trying to support multiple incompatible versions of APIs in your dependencies is a bad place to be as a library and can snowball, especially if your dependencies aren't going to try to follow SemVer in practice or give deprecation warnings in advance. Trying to have releases like v0.3.0
that would say anything above panda-client
v1.0.0
as valid (so including v1.4.81
) make it possible for pip
to realize that it should install v0.3.0
if there is an explicit requirement on panda-client<1.4.82
and allow for v0.3.1
and later to still work fine. But without updating lower bounds pip
can't do the dependency solving for you.
This PR requires a minimum required version of
panda-client
of1.4.82
for API stability as a follow up PR to PR #58.The backwards compatability that @kratsg added in PR #58
https://github.com/dguest/pandamonium/blob/d3923686fab6085c6e07f87e08af6c86bad8f69d/src/pandamonium/panda_kill_taskid.py#L12-L19
should be kept for sometime as at the moment
panda-client
is still older thanv1.4.82
most places.Example on ATLAS Connect:
Squash and merge commit message: