search

python-validators / validators

Python Data Validation for Humans™.
MIT License
977 stars 155 forks source link

Why isn't `http://localhost:PORT` a valid URL? #285

Closed Abuelodelanada closed 1 year ago

Abuelodelanada commented 1 year ago

Why this url: http://localhost:9093/ is not valid?

In [9]: validators.url("http://localhost:9093/")
Out[9]: ValidationFailure(func=url, args={'value': 'http://localhost:9093/'})

I'm using validatos 0.21.2 in python 3.11.4

yozachar commented 1 year ago

For the same reason that localhost is not a valid domain name. But you can still validate this by passing simple_host=True , refer parameter documentation.

$ python -c "from validators import url; print(url('http://localhost:9093/', simple_host=True))" 
True

Also from v0.21.2 it should return ValidationError instead of ValidationFailure.

$ python -c "from validators import url; print(url('htt://localhost:9093/', simple_host=True))" 
ValidationError(func=url, args={'value': 'htt://localhost:9093/', 'simple_host': True})

Please check your version with:

from validators import __version__
print(__version__)
benhoyt commented 1 year ago

I ran into this too. This is a backwards-incompatible change in validators.url in 0.21.0, as this worked fine in the previous version (0.20.0) -- is that expected? How does this library handle backwards-incompatible changes like this normally? (I'm not sure if it uses semver, though I note that it's on a 0.x as far as semver is concerned. So this kind of thing is "legal" as far as 0.x versions go, just not so nice for users. :-)

The specific PR is the "improves url module" one.

yozachar commented 1 year ago

Hi @benhoyt, sorry for the inconvenience caused.

This is a backwards-incompatible change in validators.url in 0.21.0, as this worked fine in the previous version (0.20.0) -- is that expected?

Yes, I was aware that this might happen. Ref: https://github.com/python-validators/validators/issues/268#issuecomment-1539309179.

How does this library handle backwards-incompatible changes like this normally? (I'm not sure if it uses semver, though I note that it's on a 0.x as far as semver is concerned. So this kind of thing is "legal" as far as 0.x versions go, just not so nice for users. :-)

Yes, we're trying to follow semantic versioning in the most reasonable manner. So as long as we're in 0.x.y every MINOR increment would suggest either:

From the comment in #268 referenced earlier:

Now this is a huge of number users on GitHub alone. I suspect a majority of them are acquainted with 0.20.0 on PyPI (with support for as low as Python 3.4). There's is no way we can push 0.21.1, without breaking some of their workflow.

I have a few things in mind, on how to go about addressing it, but I need to know where the author and other collaborators stand.

What I had in mind was:

I did neither. Because, the former sounded an overkill, where as the latter, naive.

I see Ben, you've quiet a long experience with software, what do you recommended to a beginner like me? Should I go with any or both of the options above or something else?

benhoyt commented 1 year ago

@joe733 Thanks for the comment and the additional context.

And thanks for asking for my input -- I appreciate that! I agree that trying to notify all the users of validators would be overkill; it also wouldn't be typical for an open source lib to do this, and probably not desired -- a lot of people wouldn't like a mass automatically-opened issue like that.

I believe the solution in cases like this is to use semver for what it's good at and bump the MAJOR version when you make a breaking change (but try to do that is infrequently as possible for the sake of your users!). To me it seems like staying on an 0.x version is a bit of a cop-out, allowing the library developer to make breaking changes whenever they want. The semver spec says:

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

Note "for initial development". But the validators library has been around for 10 years, so surely it would be a good idea to lock down a stable API? That way when you do put out a significant release with breaking changes, you can bump up the major version (from 1.x to 2.x or whatever) and that's the signal to users to "read the release notes, breaking changes ahead!" A proper non-0 major version also means users can pin to a major version (but allow minor/patch version updates) to avoid breaking their programs.

It looks like you've started contributing or taken over the maintenance of this library fairly recently (in the last few months!). Welcome to the joys (and burdens) of maintaining a popular open source library!

So personally what I'd recommend is to lock down the API (maybe just the current API if you think it's in good shape) and release a real 1.x version that's not considered "for initial development" and where not "anything may change at any time". Probably start a discussion issue with your plans and get people's feedback (at the very least other contributors, but ideally users too).