On Sep 16, 2013 8:46 AM, Dhananjay Nene dhananjay.n...@gmail.com wrote:
let me state that while I pin requirements.txt
To be just a little pedantic here- you pin version of dependencies, not the
entire requirements.txt. Just saying... 'cause, even though I may have
myself used the phrase in
On Mon, Sep 16, 2013 at 4:18 PM, Saager Mhatre saager.mha...@gmail.com wrote:
On Sep 16, 2013 8:46 AM, Dhananjay Nene dhananjay.n...@gmail.com wrote:
let me state that while I pin requirements.txt
To be just a little pedantic here- you pin version of dependencies, not the
entire
I was perhaps misunderstood. If you test (even with say travis) but without
a pinned requirements.txt, and then create a dist and later deploy the dist
onto the server using a pip install (w/o a requirements.txt) then you no
longer have a repeatability in terms of transient dependencies.
On Sun, Sep 15, 2013 at 6:44 PM, Vivek Puri vpuri.soc...@gmail.com wrote:
I also feel your understanding is correct. Using some form of CI like
travis is good
but it doesn't rule out pinning the requirements.
Maybe kiran has unlimited resources
I only have more experience with long term
On Sep 16, 2013 12:38 AM, Kiran Jonnalagadda j...@pobox.com wrote:
We deploy multiple times a day and I don't find that the gap between a
Travis test and production deployment is so long that an upstream release
within those few seconds broke compatibility.
Kiran
Dude, can I quote you on
Kiran Jonnalagadda j...@pobox.com writes:
[...]
I only have more experience with long term maintenance of code.
Pinned requirements == complacency == future breakage, when maintenance is
much more expensive than it is today.
We deploy multiple times a day and I don't find that the gap
On Sun, Sep 15, 2013 at 8:55 PM, Saager Mhatre saager.mha...@gmail.com wrote:
On Sep 16, 2013 12:38 AM, Kiran Jonnalagadda j...@pobox.com wrote:
We deploy multiple times a day and I don't find that the gap between a
Travis test and production deployment is so long that an upstream release
I only have more experience with long term maintenance of code.
I am quite positive that people who are in favour of pinning have
experience
in equally long term maintenance of code.
Pinned requirements == complacency == future breakage, when
maintenance is much more expensive than it is
I too have learnt the hard way how `--upgrade` can cause conflicts due
to the `pip freeze` flattening the dependency tree. What works for me
though is to keep requirements.txt completely out of picture when
upgrading packages ie. to upgrade manually and preferably do it one
package at a time as
Oh! Is that a big deal? Of course we pin our requirements (in all
languages) and that's how it should be done. Otherwise you can't get
repeatable builds. ~BG
On Thu, Sep 12, 2013 at 5:45 PM, BibhasD m...@bibhas.in wrote:
Quick googling suggests pinning = specifying versions.
I do it. I think
On Sat, Sep 14, 2013 at 2:56 PM, Noufal Ibrahim nou...@nibrahim.net.inwrote:
Baishampayan Ghose b.gh...@gmail.com writes:
Oh! Is that a big deal? Of course we pin our requirements (in all
languages) and that's how it should be done. Otherwise you can't get
repeatable builds. ~BG
I
Dhananjay Nene dhananjay.n...@gmail.com writes:
[...]
The difficulty with that approach (I've never actually done it) is
that it requires versioning these bundles, make them available to your
installation scripts and code to them (lately I've started using
ansible to do this).
I know. I
We almost never pin at HasGeek. If an external library breaks API, we
upgrade our code ASAP (we discover breakage from Travis reports).
Between the risk of breaking code and having the hot seat at any hint of
bit rot, I find the latter preferable.
Kiran
--
Kiran Jonnalagadda
On Sat, Sep 14, 2013 at 11:00 PM, Kiran Jonnalagadda j...@pobox.com wrote:
We almost never pin at HasGeek. If an external library breaks API, we
upgrade our code ASAP (we discover breakage from Travis reports).
I know I sound a little too particular, and frankly that is not my intent,
but
Thanks to Travis, we test every commit, before deployment.
--
Kiran Jonnalagadda
http://jace.zaiki.in/
http://hasgeek.com/
(Sent from my phone)
On Sep 14, 2013 11:58 PM, Dhananjay Nene dhananjay.n...@gmail.com wrote:
On Sat, Sep 14, 2013 at 11:00 PM, Kiran Jonnalagadda j...@pobox.com
wrote:
On Sun, Sep 15, 2013 at 3:43 AM, Kiran Jonnalagadda j...@pobox.com wrote:
Thanks to Travis, we test every commit, before deployment.
I was perhaps misunderstood. If you test (even with say travis) but without
a pinned requirements.txt, and then create a dist and later deploy the dist
onto the
On Sep 15, 2013 4:37 AM, Dhananjay Nene dhananjay.n...@gmail.com wrote:
On Sun, Sep 15, 2013 at 3:43 AM, Kiran Jonnalagadda j...@pobox.com
wrote:
Thanks to Travis, we test every commit, before deployment.
I was perhaps misunderstood. If you test (even with say travis) but
without
a
On Sep 13, 2013 9:19 AM, Dhananjay Nene dhananjay.n...@gmail.com wrote:
[...]
Given adequate test coverage to verify negative side effects of any
transitive dependency version upgrades, pinning could be skipped imo.
Dhananjay
+1 for automated tests to cover relevant API contracts of
Curious how many people are doing/not doing it.
(We pin our requirements.txt).
--
Thanks,
Shabda
Agiliq.com - Building Amazing Apps
agiliq.com/blog/ | github.com/agiliq
US: +13152854388 | IN: +919949997612 | Skype: shabda.raaj
Our Android Apps
What do you mean by pin? ~BG
On Thu, Sep 12, 2013 at 5:37 PM, Shabda Raaj sha...@agiliq.com wrote:
Curious how many people are doing/not doing it.
(We pin our requirements.txt).
--
Thanks,
Shabda
Agiliq.com - Building Amazing Apps
agiliq.com/blog/ | github.com/agiliq
US: +13152854388 |
Quick googling suggests pinning = specifying versions.
I do it. I think that makes more sense if you're depending on 3rd party
packages.
--
Bibhas
On Thursday 12 September 2013 05:41 PM, Baishampayan Ghose wrote:
What do you mean by pin? ~BG
On Thu, Sep 12, 2013 at 5:37 PM, Shabda Raaj
I always pin requirements. Here is a related article on the topic -
http://nvie.com/posts/pin-your-packages/
On Thu, Sep 12, 2013 at 5:45 PM, BibhasD m...@bibhas.in wrote:
Quick googling suggests pinning = specifying versions.
I do it. I think that makes more sense if you're depending on 3rd
On Thu, Sep 12, 2013 at 05:50:27PM +0530, Vineet Naik wrote:
I always pin requirements. Here is a related article on the topic -
http://nvie.com/posts/pin-your-packages/
Interesting blog link.
I did like the idea of using '==' instead of '='
___
I also pin requirements. But when I do 'pip freeze', I remove the packages
that are installed as a dependency to main libraries which were explicitly
installed.
Packages from pypi may specify dependency as = and it will fetch the
latest. But if you had pinned those too, it can cause conflicts
On Thu, Sep 12, 2013 at 6:30 PM, Abdul Muneer abdulmun...@gmail.com wrote:
I also pin requirements. But when I do 'pip freeze', I remove the packages
that are installed as a dependency to main libraries which were explicitly
installed.
I tend to avoid using 'pip freeze' as part of my dev
On Fri, Sep 13, 2013 at 12:38 AM, Saager Mhatre saager.mha...@gmail.com wrote:
On Thu, Sep 12, 2013 at 6:30 PM, Abdul Muneer abdulmun...@gmail.com wrote:
I also pin requirements. But when I do 'pip freeze', I remove the packages
that are installed as a dependency to main libraries which were
26 matches
Mail list logo
