-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Upgrade all packages using pur
tool
#2916
Conversation
@agjohnson is this something that we want or do we prefer to upgrade packages one by one? Let me know, so I can update the PR or just close it. |
416ab40
to
611f6ac
Compare
Updated today to the latest versions compatible with our codebase. @ericholscher @agjohnson please, let me know if you are interested on these kind of upgrade or not.
|
I think it's a good practice. I will let this sit until Friday then merge it, so we can do some local testing etc on it before deploy. |
It's Friday night here, nobody is around and Xmas is comming this weekend. So, maybe it's a better idea to merge this next week :) |
requirements/pip.txt
Outdated
mkdocs==0.14.0 | ||
django==1.9.12 | ||
six==1.10.0 | ||
mkdocs==0.17.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't support mkdocs==0.17
, not sure if we want this here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? Do we you have an example where it fails?
I could write a test to make it fail so we don't hit this issue again and downgrade to 0.14.0
as it was before this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mkdocs 0.17
doesn't work at all with RTD. They removed a feature we required. 0.16.x
was the last working version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is confusing for me.
First, why do we need mkdocs
for RTD itself? In fact, can we remove it from here? This is the requirements for the RTD project not the mkdocs
installed by default in the user builds.
I did a quick grep and I found that we have 0.14.0
in the RTD reqs and 0.15.0
in the reqs for user builds:
$ rg mkdocs=
requirements/pip.txt
9:mkdocs==0.14.0
readthedocs/doc_builder/python_environments.py
215: requirements.append('mkdocs==0.15.0')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pinned to 0.15.0 --the same that we install by default in the venvs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know which feature was removed in 0.17? There's at least one ticket (#3991) where the recommended fix from an mkdocs contributor was to upgrade.
7d957d7
to
5b18aac
Compare
@agjohnson I updated this PR with the latest packages |
I didn't touch the
Should I commit this changes? Is it safe? |
You may want to upgrade to |
@xrmx I didn't upgrade it because it pinned to a very specific commit from a fork of the original repo (I tried upgrading it and test failed) --and as I don't know the main reason I prefered to leave it as it was. In fact, in the issue you linked here, they are talking about some problems with that package and they don't know how to fix it. So, I wouldn't touch it without knowing the implicances. Maybe, as they are saying is good to remove that dependency after a research on how it would affect. |
c46bdb0
to
814a20d
Compare
Tow more related PRs that I wanted to include in this branch:
|
@xrmx maybe you are interested in my last two PRs from my last comment :) |
@humitos nice, thanks! |
Wondering if pyelasticsearch can be dropped, git grep pyelasticsearch returns nothing and (current) haystack uses elasticsearch-py. |
@xrmx maybe. How elasticsearch works currently in production is a mistery for me, so I didn't want to get involved on that. As I don't have experience with that I didn't touch it. |
@humitos if nobody uses it, what can it break? Anyway i've removed it from my local installation and nothing changed. |
@xrmx I'm not saying that nobody uses it. I'm saying that I don't know how it's used, if it is and that's why I didn't wanted to remove it. The search engine is complex (in fact, you opened another issue saying that it doesn't work your local instance). So, you don't know if it doesn't break things. |
elasticsearch is indeed used, it shouldn't be removed. This has a high breakage potential. We should plan on merging on a week where we have plenty of eyes on the deploy. I don't have any strong feedback here otherwise, so effectively +1. Perhaps next week we can merge early, QA, then deploy midweek? |
@agjohnson agree with you. Let me know what to do with the |
@agjohnson we were talking about pyelasticsearch not elasticsearch :) |
@humitos we have mkdocs there so that people running it locally can build mkdocs docs. This is less important now that we have docker support. There is likely a lot that could be removed that is a build dependency, but not required for basic dev. |
@ericholscher thanks for the explanation about this. Considering what you have said, I think it's a good idea to split our Besides, it easier to know what dependency is for. What do you think? I will downgrade |
Big +1 on simplifying the requirements file for local dev. It should def. be in another PR, but I think it is a big reason that people have a hard time getting started, so reducing the "time to running local instance" is a good metric to increase contribution! |
These ones were not upgraded since they are incompatible: * docker-py * celery * elasticsearch * pyelasticsearch
pur --skip django,docker-py,elasticsearch,pyelasticsearch and some packages pinned manually to avoid conflicts with our tests.
In 6.x changelog > DocParser has been renamed to Parser. https://github.com/rtfd/CommonMark-py/releases/tag/0.6.0 and that it's not compatible with the latest version of recommonmark (0.4.0)
It doesn't receive arguments and can't be used at that point because it was called previously by the other POST on the API: https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock.assert_not_called
$ pur --skip django-tastypie,django,docker-py,elasticsearch,pyelasticsearch,commonmark,stripe,djangorestframework
django-allauth 0.33.0 doesn't support Django 1.9.x which is the version we are using at the moment.
This version is the one installed by default on the venv to build the user's documentation.
5002a10
to
3ce5a4c
Compare
Rebased this, should hopefully be able to be merged after tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mocks and random methods names...
`Project.superprojects.all()` returns `ProjectRelationship` instances where we need to use the `parent` or `child` attribute to access to the project itself. (we were sending the `ProjectRelationship.pk`)
I think we are all good now. Some context:
|
Nice! I wonder if this actually resolves some of the problems with symlinking that we noticed in the deploys. I'll go ahead and merge this and the docker upgrade as well. |
These ones were not upgraded since they are incompatible:
This is just a way to run all the test with this environment and also to discuss with other people if this is something we really want.
Closes #1893