Pin core dependencies

[gsilvapt]

To make builds more reproducible, as well as errors, please specify the Python version you guys are supporting also lock the versions of your requirement files you guys created.

You're following a not very traditional approach to the requirements, by the way.. It should be something like:

requirements.txt -> contains the requirements to have the application running.
requirements_dev.txt -> contains developer-specific requirements like test suites and others alike.
requirements_prod.txt -> contains production-specific requirements if you have those.

Otherwise, it will be really hard to tackle issues like #184

[andrewgy8]

Hi @gsilvapt ! Thanks for checking us out.

lock the versions of your requirement files

Do you mean using something like Pipenv?

What do you mean by specify the python version? We have specified which versions we support in the setup.py and include in our CI, but we don't require a particular python version. That is up to the user to decide in his/her application.

As far as the requirements files go, we have split the requirements following a similar pattern. Is there a benefit that we have overlooked that the specific naming you mention provides? I have not heard of any traditional approach like your example.

Thanks

[gsilvapt]

Do you mean using something like Pipenv?

No, I meant the versions you are using your project as dependencies. The requirements file, should mention what versions of the packages you are using. Otherwise things will break and it will be very hard to know the reason.

What do you mean by specify the python version? We have specified which versions we support in the setup.py and include in our CI, but we don't require a particular python version. That is up to the user to decide in his/her application.

There are some changes between Python 3.6 all the way through 3.8. I guess specifying the supported versions would be a plus.

As far as the requirements files go, we have split the requirements following a similar pattern. Is there a benefit that we have overlooked that the specific naming you mention provides? I have not heard of any traditional approach like your example.

I guess the only advantage would be convention and simplicity. There's a base requirement file that is empty, so...

[andrewgy8]

I guess specifying the supported versions would be a plus.

How about on the README?

There's a base requirement file that is empty

Yeah its empty except for a period. That period is actually a cool feature which allows you to define the requirements in the setup.py but still allow you to install from pip. Its a way to remain DRY in a python project where your requirements maybe defined twice.

[gsilvapt]

How about on the README?

Yes, sorry, I skipped that for some reason 😃

Yeah its empty except for a period. That period is actually a cool feature which allows you to define the requirements in the setup.py but still allow you to install from pip. Its a way to remain DRY in a python project where your requirements maybe defined twice.

Cool 😄

[andrewgy8]

The requirements file, should mention what versions of the packages you are using.

I do think this is a valid point though. And I will leave the issue open for discussion on this. Its a tough call.

As maintainers, you dont want to restrict users on what they use on their projects. For example, if we say we only support Django <3.0 and someone wants to use Django 4.0, should Relé stand in the way of that?

However, I have heard some people wanting pinned versions in Relé. And I understand this, since you dont really want to mess around with Google sub dependencies, and get a nice suprise one day. (like we did with google pubsub >2.0)

[andrewgy8]

After writing this, then I dont see why we cant pin core dependencies (google-auth and google-pubsub) and leave unrelated stuff like Django, Flask, etc. unpinned.

[gsilvapt]

For me, it really depends on how you guys are using this.

The idea is to not block future versions or block people from using more recent versions. The goal is to avoid these surprises and also to make environments reproducible. If we're working on the same issue and I'm on Django 3 but you are on 4, there's so many variables that stake that could justify stuff going wrong.

If you are proactively using and maintaining this tool, then you should have an internal updating policy, and update requirements versions every now and then. That's what I observe in solid projects, I'm not trying to say it is the only approach :) I do feel that it brings the best of both worlds to a project - reproducibility, and keeping things up to date.

But, ultimately, this is your project and this is just a suggestion from a guy on the internet 😀

[andrewgy8]

No worries, we always appreciate the input!

Just looking at some other popular projects out there, it seems like they mostly "soft" pin their core dependencies.

• https://github.com/celery/celery/blob/master/requirements/default.txt
• https://github.com/encode/django-rest-framework/blob/master/setup.py#L85
• https://github.com/pallets/flask/blob/master/setup.py#L13