You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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. :-)
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: #268 (comment).
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:
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:
either use GitHub API to notify all the users of validators about breaking changes in v0.21.0, by opening an issue on their repository.
or put up a banner in this repository shouting "BREAKING CHANGES AHEAD!"
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?
@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).
Activity
nandgator commentedon Aug 13, 2023
For the same reason that
localhostis not a valid domain name. But you can still validate this by passingsimple_host=True, refer parameter documentation.Also from
v0.21.2it should returnValidationErrorinstead ofValidationFailure.Please check your version with:
[-]Expecting this URL to be successfully validated[/-][+]Why isn't `http://localhost:PORT` a valid URL?[/+]benhoyt commentedon Aug 14, 2023
I ran into this too. This is a backwards-incompatible change in
validators.urlin 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.
Fix broken test due to breaking change in validators library
nandgator commentedon Aug 14, 2023
Hi @benhoyt, sorry for the inconvenience caused.
Yes, I was aware that this might happen. Ref: #268 (comment).
Yes, we're trying to follow semantic versioning in the most reasonable manner. So as long as we're in
0.x.yeveryMINORincrement would suggest either:From the comment in #268 referenced earlier:
What I had in mind was:
validatorsabout breaking changes inv0.21.0, by opening an issue on their repository.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 commentedon Aug 14, 2023
@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
validatorswould 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:
Note "for initial development". But the
validatorslibrary 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).
Fix broken test due to breaking change in validators library (#181)
fix: simple hostname validation regex
fix: simple hostname validation regex