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.

Sign up for GitHub

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

Briefed about what are pinned deps. #1341

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Briefed about what are pinned deps. #1341

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
f02e6d7
Update pinned deps.
PrernaSingh587 Apr 8, 2021
f64a204
Rephrasing
PrernaSingh587 Apr 8, 2021
0822172
Update src/maintainer/pinning_deps.rst
PrernaSingh587 Apr 9, 2021
a301b6b
Update src/maintainer/pinning_deps.rst
PrernaSingh587 Apr 9, 2021
1acd982
Update pinning_deps.rst
PrernaSingh587 Apr 9, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions src/maintainer/pinning_deps.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,20 @@
Pinned dependencies
*******************

**Pinning a dependency** is the practice of explicitly pointing to the version of a library which our package is linked with.
A pinned dependency , for example, can look like this : ``numpy==1.1.3`` . On the other hand, a non-pinned dependency would be just: ``numpy``.

**Why to pin your dependencies?**

Explicitly declaring the versions of the dependencies could be advantageous to the quality of the software and to the developers and the open source community that makes up the software ecosystem.

* Pinning our dependencies may help in avoiding a situation where our software does not build or run due to the release of newer versions of the dependencies which are incompatible with our software, consisting some breaking changes.
* Not updating the pinned dependencies each time we upgrade our software and deploy it with newer versions of those dependencies, can result in an older version to hang around longer than it should, which can pose difficulties if these older version have some security issues. These older versions might also be incompatible with some new dependency that is introduced.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is kind of confusing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole part, or just the second point? "Not updating the pinned dependencies...."
@viniciusdc

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the second one


While its good on many levels to get your versions of dependencies explicit, it might not always be a good choice to pin them in all the cases.
By not pinning the dependencies , especially the non-crucial ones, we provide fewer constraints on the software and make it easier to incorporate into an existing software stack.
Case in point, Suppose ``numpy==1.1.3`` has been specified / pinned for a software 'A'. There is a person with ``numpy 1.1.4`` already there in their system. If they try to install this package 'A', they will have to downgrade numpy to meet the package dependencies or create a new Python environment just to use our package. However, if we specify ``numpy>=1.1.3`` ( i.e. not pinning it to a certain version but to a range of versions) , the package will be installed smoothly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I got the point here, but would you mind rephrase this? "already there in his system, tries to install this package, they will have to downgrade" I needed some air here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ohkay , I would get back with something better on this part

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you check for this one? I have made slight changes to make it look more readable and easily comprehensive.

Copy link
Contributor

@croth1 croth1 Apr 9, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a short note: given the strong male bias in tech, I strongly prefer the gender neutral they over he. I tried to keep the whole docs gender neutral during the rewrite. If you prefer to use gender specific pronouns, I would mix he and she.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I would try to keep it gender neutral. I had that in mind before starting to write this but have missed out on it while writing. Thanks for your feedback :)

.. _globally_pinned_packages:

Globally pinned packages
Expand Down