From f02e6d7efbfb4eb7162a6a406270d6efd901ccdc Mon Sep 17 00:00:00 2001 From: Prerna Singh <51945896+PrernaSingh587@users.noreply.github.com> Date: Thu, 8 Apr 2021 08:42:18 +0530 Subject: [PATCH 1/5] Update pinned deps. --- src/maintainer/pinning_deps.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/maintainer/pinning_deps.rst b/src/maintainer/pinning_deps.rst index 66a413538e..5afa1edde7 100644 --- a/src/maintainer/pinning_deps.rst +++ b/src/maintainer/pinning_deps.rst @@ -3,6 +3,20 @@ Pinned dependencies ******************* +**Pinning a dependency** is a 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 builds or runs 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. + +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, If ``numpy==1.1.3`` has been specified / pinned for a software and a person with ``numpy 1.1.4`` already there in his system, tries to install this package, 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. + .. _globally_pinned_packages: Globally pinned packages From f64a204e18a1789ad87366e418dde6a3988dd1f7 Mon Sep 17 00:00:00 2001 From: Prerna Singh <51945896+PrernaSingh587@users.noreply.github.com> Date: Thu, 8 Apr 2021 15:56:39 +0530 Subject: [PATCH 2/5] Rephrasing --- src/maintainer/pinning_deps.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/maintainer/pinning_deps.rst b/src/maintainer/pinning_deps.rst index 5afa1edde7..78e2fe43e2 100644 --- a/src/maintainer/pinning_deps.rst +++ b/src/maintainer/pinning_deps.rst @@ -15,7 +15,7 @@ Explicitly declaring the versions of the dependencies could be advantageous to t 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, If ``numpy==1.1.3`` has been specified / pinned for a software and a person with ``numpy 1.1.4`` already there in his system, tries to install this package, 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. +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 his system. If he tries to install this package 'A', he 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. .. _globally_pinned_packages: From 0822172113ef4012389f57cfa578241d1d0d2d15 Mon Sep 17 00:00:00 2001 From: Prerna Singh <51945896+PrernaSingh587@users.noreply.github.com> Date: Sat, 10 Apr 2021 01:11:19 +0530 Subject: [PATCH 3/5] Update src/maintainer/pinning_deps.rst Co-authored-by: Christopher J. 'CJ' Wright --- src/maintainer/pinning_deps.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/maintainer/pinning_deps.rst b/src/maintainer/pinning_deps.rst index 78e2fe43e2..b3c2b506ef 100644 --- a/src/maintainer/pinning_deps.rst +++ b/src/maintainer/pinning_deps.rst @@ -3,7 +3,7 @@ Pinned dependencies ******************* -**Pinning a dependency** is a practice of explicitly pointing to the version of a library which our package is linked with. +**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?** From a301b6b0aa0ac673d903dacdb74346e4a61ade5c Mon Sep 17 00:00:00 2001 From: Prerna Singh <51945896+PrernaSingh587@users.noreply.github.com> Date: Sat, 10 Apr 2021 01:11:33 +0530 Subject: [PATCH 4/5] Update src/maintainer/pinning_deps.rst Co-authored-by: Christopher J. 'CJ' Wright --- src/maintainer/pinning_deps.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/maintainer/pinning_deps.rst b/src/maintainer/pinning_deps.rst index b3c2b506ef..4dc44d09f8 100644 --- a/src/maintainer/pinning_deps.rst +++ b/src/maintainer/pinning_deps.rst @@ -10,7 +10,7 @@ A pinned dependency , for example, can look like this : ``numpy==1.1.3`` . On th 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 builds or runs due to the release of newer versions of the dependencies which are incompatible with our software, consisting some breaking changes. +* 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. 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. From 1acd982e5c91fb59178b8bfe58c3d1c667a56ea4 Mon Sep 17 00:00:00 2001 From: Prerna Singh <51945896+PrernaSingh587@users.noreply.github.com> Date: Sat, 10 Apr 2021 01:14:21 +0530 Subject: [PATCH 5/5] Update pinning_deps.rst --- src/maintainer/pinning_deps.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/maintainer/pinning_deps.rst b/src/maintainer/pinning_deps.rst index 4dc44d09f8..7a259241bd 100644 --- a/src/maintainer/pinning_deps.rst +++ b/src/maintainer/pinning_deps.rst @@ -15,7 +15,7 @@ Explicitly declaring the versions of the dependencies could be advantageous to t 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 his system. If he tries to install this package 'A', he 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. +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. .. _globally_pinned_packages: