Maybe I used the wrong term in "pinning". Or maybe the tutorial should be a special case.
Say I write some code today that relies on Cornice version 0.6 and it works splendidly. Then in a few weeks/months I decide to write something similar with Cornice version 0.6 (assuming that is still the latest version) and I start by doing "pip install Cornice", there is no guarantee that I get the same set of code to start with? I might get Cornice version 0.6 running on Pyramid 1.4a1? So I need to create the full dependency list in my new project, and manually install what I need as "pip install Cornice" is no longer the easy option, right? That sounds reasonable (I guess), as it implies that the Cornice author makes no real assertion that their software works any better (bug free) with any particular version of Pyramid past, present, or future. It is up to me as the developer to run or create all the tests that assure things work together. (Or copy a previously working environment.) However, in the case of a tutorial for beginners viewing Cornice for the first time, this is a lot to expect. And if something goes wrong, it reflects most directly on the project highlighted by the tutorial, namely Cornice. I wrote a tutorial like this for a different Python web framework a while back, and it broke a few times as dependencies changed deep under the covers. I had wished that I would have set a "known good set" for the tutorial. Of course, that dooms the tutorial to one day being an artifact based on old code. But the other option is to have it not work with the newest code and make the current project look low quality when people try it out. I have probably been spoiled by Pyramid's (and formerly Repoze.BFG's) documentation always being up-to-date and everything "just working". (I know a lot of diligence and testing goes into that - so thanks to everyone involved.) That is one thing that gives me pause when looking at Pyramid Development Environments like Akhet and Khufu that are built on top of Pyramid. I know Pyramid's API is stable, but will grabbing them at the wrong time (Murphy's Law: when you are in a hurry to quick test out an idea) result in having to pick through dependencies and fix things to get them installed and working? Maybe, if they are true Pyramid Development Environments they should be pinned to the latest, stable Pyramid release until they have been tested with a new stable release. Not just pull in the latest Alpha release the way Cornice just did. If I want to try a Development Environment with the latest alpha or beta Pyramid, I will go in and change the dependency and upgrade. (I don't might things breaking as much when I am the idiot who initiated it. :-) Anyway, that is not really the problem I was having, and Cornice seems to work fine with the latest Pyramid code (once everything is installed). I'm just saying it makes me nervous when things pull in the "latest" automatically. On Wed, Dec 21, 2011 at 12:30 PM, Chris McDonough <chr...@plope.com> wrote: > On Wed, 2011-12-21 at 12:17 -0600, Steve Schmechel wrote: > > Following the tutorial did not work for me using "pip", but worked > > fine using "easy_install" (distribute). > > It was done with Python 2.7 in a virtual environment created with > > --no-site-packages. > > The error message doesn't seem to show anything useful. I'm pretty > clueless. There's a tempfile mentioned as "install-record.txt"; maybe > it has information. > > > Also, you may want to look at "pinning" the dependency versions for > > Cornice. It seems to pull in the latest of everything, which will > > likely be a problem at some point. (It pulled in the just-released > > Pyramid version 1.3a3.) > > Making a package author responsible for pinning dependencies is usually > a really poor idea, because it means the package cannot be used in > configurations where it actually does work but an old pin or a > too-conservative pin prevents it. In general, if folks want guaranteed > stability and repeatability, they are going to need to maintain their > own version pins (using a requirements.txt, a buildout.cfg, or a > self-hosted index). > > - C > > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
