Just curious, did the idea of separate indexes for current and development versions go away? I remember:
bin/easy_install -i http://dist.repoze.org/bfg/current/simple \ repoze.bfg Was it too hard to manage the private indexes? Pyramid has separate documentation for version 1.0, 1.1, 1.2, and 1.3. But if you follow any of them you end up running latest code due to this step in every version: $ bin/easy_install pyramid I guess this happened in old BFG documentation as well, since old versions were not updated updated to use a "maintenance index" after a new version was released. However, there was a separation between current and development indexes. Maybe Pyramid is more stable now and a separate development index is not worth the effort. (And the documentation is accurate right out of the gate, which is extraordinary.) On Wed, Dec 21, 2011 at 9:19 PM, Chris McDonough <[email protected]> wrote: > On Wed, 2011-12-21 at 21:03 -0600, Steve Schmechel wrote: > > 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? > > pip install -r requirements.txt likely. Or a buildout. Or a private > index with the right versions in it. > > > 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.) > > True. > > > 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. > > Unlikely. PyPI is the wild west. Using it usually produces something > that works only by the grace of god and diligence about dependencies by > developers. And for developers who have Pyramid as a dependency, it > will either work (very likely, Pyramid doesn't introduce backwards > incompatible stuff without plenty of warning), or it won't.. if it > doesn't work, then someone will complain, and the developer will either > fix it, or he won't. That's about as much promise about using PyPI to > install Pyramid as I'm willing to offer. That said, I can't even > remember the last time someone got a configuration from PyPI that didn't > work, because to one degree or another, we are in control of almost all > of Pyramid's dependencies and we try to make sure the latest stuff all > works together. > > > 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. > > You aren't the only one who feels this way. PyPI provides really, > really poor control to authors over what to make available for download. > It basically boils down to either "upload it or don't", there's no > middle ground or way to hide anything. It's totally pointless to make > an alpha release of software that people can't install, so I choose to > upload. > > For the record, buildout (zc.buildout) has an option prefer_final or > something, which ignores releases that smell like betas or alphas or > dev2938929348729 or whatever. easy_install and pip should likely grow > something like it. > > - C > > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
