Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
pylons-discuss
Home
+ new post
About this group
Join this group
Message from discussion Cornice 0.6 released
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Chris McDonough  
View profile  
 More options Dec 21 2011, 10:19 pm
From: Chris McDonough <chr...@plope.com>
Date: Wed, 21 Dec 2011 22:19:24 -0500
Local: Wed, Dec 21 2011 10:19 pm
Subject: Re: Cornice 0.6 released
Print | View thread | Show original | Report this message | Find messages by this author

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 must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google