Un-fix the versions of docopt, PyYAML, python-dateutil about pykwalify HOT 11 CLOSED

@gijzelaerr @fwtu @AlexandreDecan @crdoconnor @smalleni Fixed in unstable branch right now with this commit 8c3327e Closing issue as fixed

from pykwalify.

+1 been struggling with this
Also i think there are some imports withing the code that specifically expect 2.4.2, maybe need to look into that as well

from pykwalify.

There is no specific code inside pykwalify that requires the specefied version of python-dateutil==2.4.2 for example, it was just that version that got frozen when i did the lib a while back. They wore frozen late 2014 to early 2015.

I can possibly loosen the imports to the following without that much effort:

• PyYaml to 3.10-3.11
• docopt to 0.6.1 to 0.6.99
• python-dateutils to 2.4.0 to 2.4.99 at first, and then later it can be extended into 2.5.x series. Because it is a major patch change it is best practise to open it up this way.

from pykwalify.

Either i do this, or i will have to vendorize all the dependencies and then they can live in parralell of any other source code that you have that depends on a different version of python-dateutils for example.

from pykwalify.

What's the problem with just specifying >=3.10, >=0.6.1 and >=2.4.2 ?

Your tests ought to break if any of the dependencies introduce breaking API changes, right?

from pykwalify.

If i just say that it should have a min version, i have no control over what dependencies i have tested this lib against. If python-dateutils would put out 3.0.0 for example, it would still be valid and acceptable to use when installing this package, but i have never tested it or verified that it works or even know what has been changed, it could break everything and i would have to deal with a bigger scope of dependencies i would have to support.

If the packages is using semantic versioning the correct way, then i should specify all minor versions inside a major version, for example python-dateutil>=2.4.0,<2.5.0 at first, because that guarantees that this lib works with the latest minor version inside the 2.4.x series. If i then later expand and test it to python-dateutil>=2.4.0,<2.6.0 i will be ok with that and i can say that it should work with these versions.

One other scenario is that if i would to stop develop this software right now and have >=2.4.2 set in the requirements, and then two years pass, the lib will not automatically be tested against a new version by it self and to be verified that it works.

from pykwalify.

What if I created an automated workflow (zapier seems to be capable of this) that triggers a new build on travis that re-runs the tests when a new version of one of pykwalify's dependencies is released?

That way you'd get near-instantaneous notification of an upstream API change that causes a test failure/pass, at which point you could either fix the problem (if it's minor) or quickly introduce a ,<latest-version to setup.py if it's not.

I suspect that most of these dependencies won't be changing their API much, if at all, however.

from pykwalify.

I ran into issues with the way pykwalify specifies its dependencies since PyYAML recently updated.

You should really not fix dependencies versions for pykwalify, even if this means that a backward-incompatible update may break pykwalify. Iif this happens, people will tell you and you'll just have to fix the version constraint in that case. In the meantime, people can still manually specify which versions they want to install (eg. by installing it manually before installing pykwalify).

I hope you'll reconsider this (see #69).

from pykwalify.

Just spent half an hour tracking down some dependency issues with a CI package build to this issue. Please do not pinpoint versions of dependencies. +1 for accepting #69 asap.

from pykwalify.

I'm experiencing the same issue at moment when using pykwalify in combination with other projects. As far as I know one should not be too strict on the version number in setup.py since then you run into problems like this.

>>> pkg_resources.require("pykwalify")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/pkg_resources.py", line 725, in require
    needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources.py", line 632, in resolve
    raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (python-dateutil 2.0 (/usr/lib/python3/dist-packages), Requirement.parse('python-dateutil==2.4.2'))

from pykwalify.

Thank you!

from pykwalify.