Open Stack

On Wed, Aug 22, 2012 at 2:54 PM, Mark McLoughlin <markmc at redhat.com> wrote:
> Hi Duncan,
>
> On Wed, 2012-08-22 at 13:29 -0700, Duncan McGreggor wrote:
>> On Wed, Aug 22, 2012 at 1:04 PM, Thierry Carrez <thierry at openstack.org> wrote:
>> > Jason Kölker wrote:
>> >> On Wed, 2012-08-22 at 17:20 +0200, Thierry Carrez wrote:
>> >>> Monty Taylor wrote:
>> >>>> On 08/21/2012 10:19 AM, Mark McLoughlin wrote:
>> >>>>> Hey,
>> >>>>>
>> >>>>> On Tue, 2012-08-21 at 09:45 -0600, Monty Taylor wrote:
>> >>>>>> Hey all!
>> >>>>>>
>> >>>>>> I'd like to request a FFE for the following:
>> >>>>>>
>> >>>>>> https://review.openstack.org/#/c/11027/
>> >>>
>> >>> So I looked a bit more deeply into this, and I'm not really convinced.
>> >>>
>> >>> First, this comes out of nowhere with no blueprints / discussion, with
>> >>> first patch proposed even after Folsom-3 was pushed.
>> >>
>> >> Using entry_points was discussed at the Folsom summit. I agree with the
>> >> rest of the sentiment though, better to wait for grizzly.
>> >
>> > Yeah, I also realized after posting that one of the patches was actually
>> > posted before FF :) I guess the decision boils down to *why* this needs
>> > to be in Folsom rather than in early Grizzly, and I wish changes had
>> > been submitted a few weeks earlier so that we didn't have to lose time
>> > over that review/discussion/decision :)
>>
>> At DeamHost, we're developing against Folsom and will be releasing a
>> Folsom-based product. If this change makes it in for Folsom, this will
>> save us considerable work via an improved development process. Within
>> the larger context of the community at large we may be only one team
>> of devs, but I'd imagine that with a team as senior as ours, there
>> will be other Python hackers out there who will appreciate the
>> methodology represented by this change and the benefits of having it
>> in place for Folsom-based projects.
>
> Could you elaborate on what this new methodology is and how it will save
> you considerable work? Honestly totally non-obvious to me, I'm afraid.
>
> Thanks,
> Mark.

So Mark and I had missed that import_object_ns actually does more than
just the old behavior, but also prepends and namespace.

Without that recent change, there would have been three ways to do this:
 * entrypoints
 * full object path import
 * forking the tree and adding the code that we needed

And we viewed entrypoints as the cleanest and most standard way to do this.

However, yesterday Doug Hellmann pointed out to us that the code has
changed to support our use case.

As such, the urgency for this change has dropped for us :-)

d