Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dateparser throws module not found error becasue of regex module #505

Closed
aorfanos1 opened this issue Feb 19, 2019 · 5 comments · Fixed by #600
Closed

Dateparser throws module not found error becasue of regex module #505

aorfanos1 opened this issue Feb 19, 2019 · 5 comments · Fixed by #600

Comments

@aorfanos1
Copy link

The dateparser module is currently not building (python 3.6.1) (dateparser 0.7.1), because of the latest regex module update (2019.02.19) - our fix for this was to hardcode the regex version to a recent, but not broken point in time (2019.02.07). Just making you aware and hoping that we get a real fix for this soon. Thanks

@NickAJScott
Copy link

This looks to be caused by the setup.py not having fixed requirement versions whereas the requirements.txt file does. As a result because the regex module just released a broken package its broken the dateparser module installed via the setup.py.

@asadurski
Copy link
Member

I can see that the problem has already been fixed in regex repo (https://bitbucket.org/mrabarnett/mrab-regex/issues/314/import-error-no-module-named), with 2019.02.20 version released.
Thanks for the pointers @NickScottKortical, as you said, we'll need to pin the package versions in setup too.

@kishan3
Copy link

kishan3 commented Dec 20, 2019

I can see that the problem has already been fixed in regex repo (https://bitbucket.org/mrabarnett/mrab-regex/issues/314/import-error-no-module-named), with 2019.02.20 version released.
Thanks for the pointers @NickScottKortical, as you said, we'll need to pin the package versions in setup too.

Hi, @asadurski Can this be closed?

@Gallaecio
Copy link
Member

We might want to merge #600 first. Although it’s extremely unlikely it will save anyone at this point, so we might as well close both this and #600 (without merging).

@noviluni
Copy link
Collaborator

Agree with @Gallaecio . It's better to explicity avoid that version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Project board
Awaiting triage
Development

Successfully merging a pull request may close this issue.

6 participants