TG2 Quickstart and DB creation
percious
component architecture). I am working with Jorge and Jon to try and
get a handle on how to extend TG's database system. We are developing
a light weight CMS called Pages.
I have been working on a new paster command for pages which will allow
us to create the necessary database tables and inject the model into
an existing TG2 application. The problem here is that the creation of
the db schema and the addition of the bootstrap data is too coupled.
When you call paster setup-app, it runs both, always. I think we need
to separate the two, perhaps creating a second command which only
updates the db schema. This would also require a separation of the
websetup code. I propose a new folder with the following layout:
websetup/
__init__.py : contains setup_app which will be a combination of
bootstrap and schema setup
bootstrap.py: contains a way to bootstrap a clear database
schema_setup.py: contains the method for setting up a new database
schema, including modifying an existing one.
The problem has been that because of the internals of SA, a duplicate
record with a unique field *sometimes* causes db schema creation to
fail. By separating the concerns, we pave the way for more flexible
solutions.
cheers.
-chris
Florent Aide
>
> I have begun work on our new extensions methodology. (Some call this
> component architecture). I am working with Jorge and Jon to try and
[...]
> websetup/
> __init__.py : contains setup_app which will be a combination of
> bootstrap and schema setup
nice this will definitely make things easier.
Florent.
Mark Ramm
done in the next day or so -- otherwise it'll be a 2.1 feature.
I want it done now, but making that happen will require updating
several docs :/ So, I'm a bit hesitant to about just going for it
directly.
--Mark Ramm
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
percious
percious
I will update the necessary docs if you can point me to the right
pages.
percious
quickstart which will work as template "hooks" for extensions. I'm
not sure how many of these hooks we will need, or how we should
document them, but this is a work-in-progress.
cheers.
-chris
Mark Ramm
> quickstart which will work as template "hooks" for extensions. I'm
> not sure how many of these hooks we will need, or how we should
> document them, but this is a work-in-progress.
Could you explain a little? Hooks for template extensions, templates
for hooks to load extensions, something else?
percious
in bootstrap.py:
# <bootstrap.before.user.data>
# <bootstrap.after.user.data>
in root.py:
# <rootcontroller.after.class.statement>
# <rootcontroller.eof>
etc.
Daniel Fetchinson
> component architecture). I am working with Jorge and Jon to try and
> get a handle on how to extend TG's database system. We are developing
> a light weight CMS called Pages.
This is good to hear! Just one comment: call it something else than
Pages, otherwise it will be a pain to search for any related
information on google.
Cheers,
Daniel
> I have been working on a new paster command for pages which will allow
> us to create the necessary database tables and inject the model into
> an existing TG2 application. The problem here is that the creation of
> the db schema and the addition of the bootstrap data is too coupled.
> When you call paster setup-app, it runs both, always. I think we need
> to separate the two, perhaps creating a second command which only
> updates the db schema. This would also require a separation of the
> websetup code. I propose a new folder with the following layout:
>
> websetup/
> __init__.py : contains setup_app which will be a combination of
> bootstrap and schema setup
> bootstrap.py: contains a way to bootstrap a clear database
> schema_setup.py: contains the method for setting up a new database
> schema, including modifying an existing one.
>
> The problem has been that because of the internals of SA, a duplicate
> record with a unique field *sometimes* causes db schema creation to
> fail. By separating the concerns, we pave the way for more flexible
> solutions.
>
> cheers.
> -chris
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Jorge Vargas
>
> Works for me. We can try to shoehorn this into rc1 if we can get it
> done in the next day or so -- otherwise it'll be a 2.1 feature.
>
> I want it done now, but making that happen will require updating
> several docs :/ So, I'm a bit hesitant to about just going for it
> directly.
>
Jorge Vargas
>
I don't like this idea a lot, I think we should rethink how the whole
paster template stuff is handled, maybe we should replace it with
something that supports updates and merging (input from several files)
Jorge Vargas
<fetch...@googlemail.com> wrote:
>
>> I have begun work on our new extensions methodology. (Some call this
>> component architecture). I am working with Jorge and Jon to try and
>> get a handle on how to extend TG's database system. We are developing
>> a light weight CMS called Pages.
>
> This is good to hear! Just one comment: call it something else than
> Pages, otherwise it will be a pain to search for any related
> information on google.
>
names suggestions are welcome. We may change again :)
Jorge Vargas
On Tue, Mar 17, 2009 at 10:38 PM, Jorge Vargas <jorge....@gmail.com> wrote:
> On Tue, Mar 17, 2009 at 2:05 PM, Mark Ramm <mark.mch...@gmail.com> wrote:
>>
>> Works for me. We can try to shoehorn this into rc1 if we can get it
>> done in the next day or so -- otherwise it'll be a 2.1 feature.
>>
> -1 I think this is all tg2.1 stuff (together with my controller split)
>
makes docs out dated. I'm +1 on the whole idea.
percious
I implemented this last night. There are currently no separate
commands, and setup-app still functions as before with a little bit
more of a robust setup. I added some of the hooks into only the
websetup stuff. I verified this works with a fresh qs.
These changes make it easier for one to hook tgext.pages into any tg
project.
There are 4 places in the current docs that need updating, I will try
and do it in the morning.
cheers.
-chris
> On Tue, Mar 17, 2009 at 10:38 PM, Jorge Vargas <jorge.var...@gmail.com> wrote:
>
> >> Works for me. We can try to shoehorn this into rc1 if we can get it
> >> done in the next day or so -- otherwise it'll be a 2.1 feature.
>
> > -1 I think this is all tg2.1 stuff (together with my controller split)
>
> I'm -1 of it going into 2.0 if it's not backwards compatible and/or
> makes docs out dated. I'm +1 on the whole idea.
>
> >> I want it done now, but making that happen will require updating
> >> several docs :/ So, I'm a bit hesitant to about just going for it
> >> directly.
>
> > my point too.
>
> >> --Mark Ramm
>
Gustavo Narea
If we're supposed to be in a feature-freeze, that's for people to be confident
that from now on things aren't going to change, unless a critical bug has to
be fixed, so that they can start building software and writing about TG2 with
the guarantee that their product isn't going to expire some days later.
I love to see TG2 evolve, but that this has been applied in the feature-frozen
branch I'm using to write a short series of articles using TG2 and that it
already out dates the first article (which was delivered)... It really bothers
me.
If I can't trust that we were serious when we announced that feature freeze,
then I'll switch over to a truly stable framework for my next article.
On the other hand, independent of the article I wrote, I think we must comply
with the feature freeze strictly, specially in non-trivial changes like this
(splitting a function into three ones, defined in newly-created modules each).
The more complex a change is, the more chances to introduce a bug. And at this
point we shouldn't take the risk of introducing bugs, but just fix the
remaining ones.
Finally, I think this change has to be moved to the upcoming 2.1 branch
(trunk, when there's a 2.0 branch). I love the idea, I think think it's
reasonable, but I think it's too late to go in v2.0. Otherwise, this will be
bad for PRs.
Cheers,
=Gustavo
On Tuesday March 17, 2009 19:05:50 Mark Ramm wrote:
> Works for me. We can try to shoehorn this into rc1 if we can get it
> done in the next day or so -- otherwise it'll be a 2.1 feature.
>
> I want it done now, but making that happen will require updating
> several docs :/ So, I'm a bit hesitant to about just going for it
> directly.
>
> --Mark Ramm
>
> On Tue, Mar 17, 2009 at 1:53 PM, Florent Aide <floren...@gmail.com>
wrote:
> > On Tue, Mar 17, 2009 at 4:56 PM, percious <ch...@percious.com> wrote:
> >> I have begun work on our new extensions methodology. (Some call this
> >> component architecture). I am working with Jorge and Jon to try and
> >
> > [...]
> >
> >> websetup/
> >> __init__.py : contains setup_app which will be a combination of
> >> bootstrap and schema setup
> >
> > nice this will definitely make things easier.
> >
> > Florent.
--
Gustavo Narea <xri://=Gustavo>.
| Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about |
Mark Ramm
the change, I think I'm back to thinking this will be a 2.1 feature.
But I know it's nice stuff and nesissary for tgext.pages, but the
component stuff is a 2.1 goal, and we do have a feature freeze going
on, and I need to be more hardcore about enforcing that.
If we can release 2.0 final, and 2.1 a few weeks later, I'm fine with
that, but I don't want to delay or break 2.0 ;) So, to hopefully make
everybody happy, I say we leave this in trunk and declare trunk the
place for 2.1 work, and I'll create a 2.0 branch right away, based on
the rev before this change for the rc1 release.
What do you think?
percious
mentioned this after I had already implemented.
percious
pycon. We need to be able to easily branch on stuff like this.
Also, i have every confidence that this change will not introduce
errors. I will also be online almost continuously over the next few
weeks for support (9-9 MDT)
cheers.
-chris
Mark Ramm
away -- and that branch will be called trunk. ;)
I will also branch off the 2.0 docs for polishing, and leave your new
docs in trunk.
--Mark Ramm
Jorge Vargas
>
> If we're supposed to be in a feature-freeze, that's for people to be confident
> that from now on things aren't going to change, unless a critical bug has to
> be fixed, so that they can start building software and writing about TG2 with
> the guarantee that their product isn't going to expire some days later.
>
API is keep intact (which from talking to precious) I believe it was.
then the change can go into the feature freeze and nothing should
break. And it is not a big problem. This isn't really a new feature is
spliting it in half. And making the old one call the 2 new ones. It's
more like refractoring and the first rule of refractoring is that you
should not break anything.
> On the other hand, independent of the article I wrote, I think we must comply
> with the feature freeze strictly, specially in non-trivial changes like this
> (splitting a function into three ones, defined in newly-created modules each).
>
harmless as splitting a file in two
> The more complex a change is, the more chances to introduce a bug. And at this
> point we shouldn't take the risk of introducing bugs, but just fix the
> remaining ones.
>
think we can all agree he has never broken the trunk.
> Finally, I think this change has to be moved to the upcoming 2.1 branch
> (trunk, when there's a 2.0 branch). I love the idea, I think think it's
> reasonable, but I think it's too late to go in v2.0. Otherwise, this will be
> bad for PRs.
>
threw a snowball on me.
In order to get started with the new turbogears.org we need pages 0.1
released which now depends on this, which means we need TG2.1 which is
unreleased, which means I need to either break the security policy of
the server (installing unreleased software) or install a hacked
version of TG2.0rc1 in order to get this going.
And as I said above this is all api stable, nothing will break with
the FIRST stage of the changes (needed for pages) the second set of
changes should be 2.1 only.
my 2 cents
Mark Ramm
after quickstart and never "install" 2.1 and there are several issues
that go into a feature freeze:
1) potential for breaking things
2) need to rewrite docs
3) need for public blog posts, articles, etc to work with the released version
And I put them in the order of imporance I think they have. But I do
think that making the code in a python magazine article "just work" is
worth the trouble of 2.0 users having to split this apart manually. I
know that sucks a little bit for pages, but the bad marketing of
having a magazine article go to thousands of people with code that
does not work out of the box is worse.
And from Gustavo's message I assume that he had people put extra
bootstrap data into websetup.py and showed that in the article --
which is what would be broken by chris's change.
--Mark
Gustavo Narea
On Sunday March 22, 2009 22:02:42 Jorge Vargas wrote:
> > If we're supposed to be in a feature-freeze, that's for people to be
> > confident that from now on things aren't going to change, unless a
> > critical bug has to be fixed, so that they can start building software
> > and writing about TG2 with the guarantee that their product isn't going
> > to expire some days later.
>
> I think you missed the point either here or of feature freeze. if the
> API is keep intact (which from talking to precious) I believe it was.
> then the change can go into the feature freeze and nothing should
> break. And it is not a big problem. This isn't really a new feature is
> spliting it in half. And making the old one call the 2 new ones. It's
> more like refractoring and the first rule of refractoring is that you
> should not break anything.
Of course the API changed! There are two new modules and two new functions.
And of course it's a refactoring. Nobody here said the opposite. I agree, it's
a much needed refactoring, but it's changing the API and isn't fixing a bug,
so from my point of view it shouldn't be applied in a feature-frozen branch.
If you think that I missed the point of a feature freeze, then I guess we have
different concepts of what it is. Mine is that nothing must change unless
there's a bug to be fixed (enhancements out); and I'd say that I'm not alone.
> > On the other hand, independent of the article I wrote, I think we must
> > comply with the feature freeze strictly, specially in non-trivial changes
> > like this (splitting a function into three ones, defined in newly-created
> > modules each).
>
> again that is not feature freeze it's just code cleanup, this is as
> harmless as splitting a file in two
"cleanup" sounds nicer, agreed. But, well, you can describe it as
"refactoring", "enhancement", etc... But not as a "cleanup". Where's the
"cleanup"?
I repeat, I support the change, I think it makes sense, I think it's
absolutely necessary. But I'm opposed to the following things in a feature
freeze:
1.- Adding features (as the name implies),
2.- Changing the API. Even if it's backwards compatible and thus won't break
the software, it will definitely outdate text written relying on the part of
the API that changed.
> > The more complex a change is, the more chances to introduce a bug. And at
> > this point we shouldn't take the risk of introducing bugs, but just fix
> > the remaining ones.
>
> Right I do agree with you on this, but from Chris commit history I
> think we can all agree he has never broken the trunk.
Chris P is a brilliant developer, I know, but it's not about who makes the
changes, it's about we're all human -- We are all error-prone.
The thing is that at this point we can't afford making mistakes. "If it ain't
broken, don't fix it" should be our motto for the 2.0 branch -- there we
should fix broken stuff, not inefficient stuff.
The 2.1 branch should be to fix both broken and inefficient stuff.
> > Finally, I think this change has to be moved to the upcoming 2.1 branch
> > (trunk, when there's a 2.0 branch). I love the idea, I think think it's
> > reasonable, but I think it's too late to go in v2.0. Otherwise, this will
> > be bad for PRs.
>
> So the final decision on this is to keep it out? because that just
> threw a snowball on me.
"Keep it out"? Who suggested that? I suggested that it was moved to the 2.1
branch, not discarded.
> In order to get started with the new turbogears.org we need pages 0.1
> released which now depends on this, which means we need TG2.1 which is
> unreleased, which means I need to either break the security policy of
> the server (installing unreleased software) or install a hacked
> version of TG2.0rc1 in order to get this going.
I understand the problem, and I'm sorry that this inefficiency was found this
late.
> And as I said above this is all api stable, nothing will break with
> the FIRST stage of the changes (needed for pages) the second set of
> changes should be 2.1 only.
It wouldn't be stable if it changed. Stable is stable.
I agree that Chris' changeset works and is a backwards compatible API change,
as well as that I didn't find a bug in it. But:
1.- It's not only about the software being backwards compatible. It's about
having an stable API to give people the confidence that they can write text on
its current API which won't get outdated a few days later.
2.- If it ain't broken, don't fix it. You'd take the risk of introducing
bugs.
Cheers.
Gustavo Narea
On Sunday March 22, 2009 23:11:48 Mark Ramm wrote:
> And from Gustavo's message I assume that he had people put extra
> bootstrap data into websetup.py and showed that in the article --
> which is what would be broken by chris's change.
Yes, exactly.
Cheers!
Jorge Vargas
old code http://trac.turbogears.org/browser/projects/tg.devtools/trunk/devtools/templates/turbogears/%2Bpackage%2B/websetup.py_tmpl?rev=6511
new code http://trac.turbogears.org/browser/projects/tg.devtools/trunk/devtools/templates/turbogears/%2Bpackage%2B/websetup/__init__.py_tmpl?rev=6513
usage:
from <project> import websetup
setup_app(command, conf, vars)
please tell me how the calling code changes from A to B ? It doesn't!
so please do not say that is an api change, it isn't.
The only think that could be affected by that change is that if you
told someone to edit websetup.py instead of websetup.
So why not look for a mid ground instead of killing the feature? make
it back into a single websetup.py and let it be split into 2 functions
all in the same file, everyone is happy, then make it a module for 2.1
It seems to me everyone saw a bunch of files be moved in
http://trac.turbogears.org/changeset/6513 and didn't realize how
trivial is that.
Now lets see the feature freeze was supposed to be feb-28 (from ML
archives) yet if you look at
http://trac.turbogears.org/log/projects/tg.devtools/trunk/devtools/templates,
we'll have to remove
- the move of the ModelTest class (which I didn't because we where in
api freeze)
- all the new model tests
- all the new auth tests
so what's it going to be are we willing to "lose" all the last changes
(and confuse everyone running trunk) or we are going to look for a
solution?
Gustavo Narea
> Please explain me why this is API change?
> please tell me how the calling code changes from A to B ? It doesn't!
> so please do not say that is an api change, it isn't.
I repeat: If you add two public modules and two public functions, then you're
changing the API. I'd say it's pretty obvious.
You seem to believe that API change == backwards-incompatible change, and
you'd be wrong. You can make backwards compatible changes in the API -- for
example, the one we're talking about.
Nobody but you is talking about backwards incompatibility. Of course that
function can be called as usual, it's backwards compatible! So what? Who's
said it's backwards incompatible? Nobody.
My point is that it's an API change and that always outdates text written
relying on the part of the API that changed. Period. I didn't say that
function has to be called differently since that change.
> The only think that could be affected by that change is that if you
> told someone to edit websetup.py instead of websetup.
Why? Because it's an API change!
> So why not look for a mid ground instead of killing the feature? make
> it back into a single websetup.py and let it be split into 2 functions
> all in the same file, everyone is happy, then make it a module for 2.1
>
> It seems to me everyone saw a bunch of files be moved in
> http://trac.turbogears.org/changeset/6513 and didn't realize how
> trivial is that.
>
> Now lets see the feature freeze was supposed to be feb-28 (from ML
> archives) yet if you look at
> http://trac.turbogears.org/log/projects/tg.devtools/trunk/devtools/template
>s, we'll have to remove
>
> - the move of the ModelTest class (which I didn't because we where in
> api freeze)
> - all the new model tests
> - all the new auth tests
For your information, those three items were taken as *blocker* *issues* and I
had *explicit* *permission* to implement them right away.
> so what's it going to be are we willing to "lose" all the last changes
Will you continue referring to moving that enhancement to 2.1 as a "lost" or
"discard"?
> (and confuse everyone running trunk)
Confuse everybody running trunk? Here and in every single project it's more
than explicit that if you use the mainline development, you'd be doing it at
your own risk.
So that's not a reason to be taken into account.
> or we are going to look for a solution?
I think that's what we're doing.
Cheers.
Jorge Vargas
>
> On Monday March 23, 2009 07:29:54 Jorge Vargas wrote:
>> Please explain me why this is API change?
>> <snip>
>> please tell me how the calling code changes from A to B ? It doesn't!
>> so please do not say that is an api change, it isn't.
>
> I repeat: If you add two public modules and two public functions, then you're
> changing the API. I'd say it's pretty obvious.
>
anymore, you can't seriously think they are "public" api in python
there is no such thing about that. And those functions are never
called from the outside unless you are doing something special (like
pages, which is a prototype of a tg2.1 app)
> You seem to believe that API change == backwards-incompatible change, and
> you'd be wrong. You can make backwards compatible changes in the API -- for
> example, the one we're talking about.
>
it's because you need it if you don't use it then what's the big deal?
> My point is that it's an API change and that always outdates text written
> relying on the part of the API that changed. Period. I didn't say that
> function has to be called differently since that change.
>
I can see that your "text is outdated" if you simply said "now add to
your websetup at the end of it the following code" they should be no
outdated article.
>
>> The only think that could be affected by that change is that if you
>> told someone to edit websetup.py instead of websetup.
>
> Why? Because it's an API change!
>
your response.
> For your information, those three items were taken as *blocker* *issues* and I
> had *explicit* *permission* to implement them right away.
>
this thread. that's everyone saying +1
>
>> so what's it going to be are we willing to "lose" all the last changes
>
> Will you continue referring to moving that enhancement to 2.1 as a "lost" or
> "discard"?
>
>
>> (and confuse everyone running trunk)
>
> Confuse everybody running trunk? Here and in every single project it's more
> than explicit that if you use the mainline development, you'd be doing it at
> your own risk.
>
believe TG is one of those.
> So that's not a reason to be taken into account.
>
>
>> or we are going to look for a solution?
>
> I think that's what we're doing.
>
I got "wrong" and yet it seems you skip the sole paragraph where I
proposed a solution that will get everyone happy.
percious
about 30 seconds.
$ paster quickstart tgtest
$ cd tgtest
$ paster setup-app development.ini
<change model>
$ pastser setup-app development.ini
<error ensues>
My change fixes this bug and is a minor refactor. This is the biggest
reason I re-wrote that code, and if you want me to post a bug on it I
will. And I agree with Jorge, it's not an api change due to the fact
that the same external imports are functional.
API = application programming interface,
~ not ~
application programming internals.
cheers.
-chris
On Mar 23, 6:02 am, Gustavo Narea <m...@gustavonarea.net> wrote:
> On Monday March 23, 2009 07:29:54 Jorge Vargas wrote:
>
> > Please explain me why this is API change?
> > <snip>
> > please tell me how the calling code changes from A to B ? It doesn't!
> > so please do not say that is an api change, it isn't.
>
> I repeat: If you add two public modules and two public functions, then you're
> changing the API. I'd say it's pretty obvious.
>
> You seem to believe that API change == backwards-incompatible change, and
> you'd be wrong. You can make backwards compatible changes in the API -- for
> example, the one we're talking about.
>
> Nobody but you is talking about backwards incompatibility. Of course that
> function can be called as usual, it's backwards compatible! So what? Who's
> said it's backwards incompatible? Nobody.
>
> My point is that it's an API change and that always outdates text written
> relying on the part of the API that changed. Period. I didn't say that
> function has to be called differently since that change.
>
> > The only think that could be affected by that change is that if you
> > told someone to edit websetup.py instead of websetup.
>
> Why? Because it's an API change!
>
>
>
> > So why not look for a mid ground instead of killing the feature? make
> > it back into a single websetup.py and let it be split into 2 functions
> > all in the same file, everyone is happy, then make it a module for 2.1
>
> > It seems to me everyone saw a bunch of files be moved in
>
> > Now lets see the feature freeze was supposed to be feb-28 (from ML
> > archives) yet if you look at
Gustavo Narea
> On Mon, Mar 23, 2009 at 8:02 AM, Gustavo Narea <m...@gustavonarea.net> wrote:
> > On Monday March 23, 2009 07:29:54 Jorge Vargas wrote:
> >> Please explain me why this is API change?
> >> <snip>
> >> please tell me how the calling code changes from A to B ? It doesn't!
> >> so please do not say that is an api change, it isn't.
> >
> > I repeat: If you add two public modules and two public functions, then
> > you're changing the API. I'd say it's pretty obvious.
>
> then stick a _ in there and add a __all__ and they are not "public"
> anymore, you can't seriously think they are "public" api in python
> there is no such thing about that. And those functions are never
> called from the outside unless you are doing something special (like
> pages, which is a prototype of a tg2.1 app)
By "public" I meant user-accessible, not the sense of "public" in programming
languages like Java or PHP.
Every single function/class/module in quickstarted applications are public
because they are all user-accessible. So, if you add functions and modules,
they'll be public. And if they're public, you _modified_ the API to add
services.
> > You seem to believe that API change == backwards-incompatible change, and
> > you'd be wrong. You can make backwards compatible changes in the API --
> > for example, the one we're talking about.
>
> I have never seen adding a method as a bad API change, if you use it
> it's because you need it if you don't use it then what's the big deal?
Heh... Now you're implicitly accepting it was an API change, but not a bad
one. ;)
I agree, it's not bad, but it's late to go in TG 2.0.
> > My point is that it's an API change and that always outdates text written
> > relying on the part of the API that changed. Period. I didn't say that
> > function has to be called differently since that change.
>
> how? did you quoted the whole file in the article? that's the only way
> I can see that your "text is outdated" if you simply said "now add to
> your websetup at the end of it the following code" they should be no
> outdated article.
You're talking about my article in particular, while I'm talking in a more
general sense: If you change an API, it's *very* likely that you'll outdate
somebody else's text on the part of the API that changed; I'd say that's a
rule of thumb.
Regarding my article in particular, I explained what the "websetup.py" file
was for and also asked to add some lines in setup_app() (referring to the file
as "websetup.py").
> >> The only think that could be affected by that change is that if you
> >> told someone to edit websetup.py instead of websetup.
> >
> > Why? Because it's an API change!
>
> YES, which I propose a way to fix that and you totally ignored it on
> your response.
At last! You accepted it was an API change!
And apologies, I slipped in that part while trying to trim the email.
My thoughts on your proposal:
1.- It'd still be an API change, it just happens to be smaller: no new
modules, but two new functions.
2.- It'd still outdate some texts, like mine where I say something like "Add
the contents of Listing N right before DBSession.flush() and commit()".
> > For your information, those three items were taken as *blocker* *issues*
> > and I had *explicit* *permission* to implement them right away.
>
> The above *also* had *explicit* permission, just look at the top of
> this thread. that's everyone saying +1
... until we saw what the change was exactly about...
> >> so what's it going to be are we willing to "lose" all the last changes
> >
> > Will you continue referring to moving that enhancement to 2.1 as a "lost"
> > or "discard"?
>
> yes you will lose it for 2.0.
"For 2.0", yes, that is accurate.
> >> (and confuse everyone running trunk)
> >
> > Confuse everybody running trunk? Here and in every single project it's
> > more than explicit that if you use the mainline development, you'd be
> > doing it at your own risk.
>
> not if you are careful a ton of projects are very trunk stable and I
> believe TG is one of those.
Here and _everywhere_ "trunk" is a "use it at your own risk" branch. That
developers are committed to keep it stable is another topic.
> > So that's not a reason to be taken into account.
> >
> >> or we are going to look for a solution?
> >
> > I think that's what we're doing.
>
> I think not, as your last response was a full "complain" of everything
> I got "wrong" and yet it seems you skip the sole paragraph where I
> proposed a solution that will get everyone happy.
Sorry again, above I explained what happened. And it doesn't make everybody
Gustavo Narea
On Monday March 23, 2009 18:46:56 percious wrote:
> Honestly guys, if you want a bug for this change I can produce one in
> about 30 seconds.
>
> $ paster quickstart tgtest
> $ cd tgtest
> $ paster setup-app development.ini
> <change model>
> $ pastser setup-app development.ini
> <error ensues>
>
> My change fixes this bug and is a minor refactor. This is the biggest
> reason I re-wrote that code, and if you want me to post a bug on it I
> will. And I agree with Jorge, it's not an api change due to the fact
> that the same external imports are functional.
I maintain that it's an backwards-compatible, API change.
But I mostly agree with you here. While I don't see that as a blocker issue, I
do think it's something we should fix by 2.0 Final.
And I'd fix it in a unobtrusive/conservative way: Implementing that try/except
block in setup_app() itself.
> API = application programming interface,
> ~ not ~
> application programming internals.
Code generated along with the application is not internal at all, at least
from my point of view.
Cheers,
Jorge Vargas
answering inline anymore. If you want to think it's api change then
fine go ahead this is no api at all as you don't even need quickstart
to have a TG2 project. If you keep insisting it changes the API fine I
won't argue about that.
In the meanwhile we have a broken tgext.pages (see the thread from
GSOC for the first user figuring that out)
But don't worry when people complain about how inflexible websetup is
we'll point them to this thread.
On Mon, Mar 23, 2009 at 2:21 PM, Gustavo Narea <m...@gustavonarea.net> wrote:
> And apologies, I slipped in that part while trying to trim the email.
>
> My thoughts on your proposal:
> 1.- It'd still be an API change, it just happens to be smaller: no new
> modules, but two new functions.
whatever, you are making a huge deal out of splitting a function into
3 logical functions which by the way everyone already does.
> 2.- It'd still outdate some texts, like mine where I say something like "Add
> the contents of Listing N right before DBSession.flush() and commit()".
>
which are probably way unflexible, and again it's totally fixable.
15 def setup_app(command, conf, vars):
16 """Place any commands to setup {{package}} here"""
17 load_environment(conf.global_conf, conf.local_conf)
18 setup_schema(command, conf, vars)
19 bootstrap(command, conf, vars)
20 DBSession.flush()
21 transaction.commit()
Mark Ramm
We can tell people installing pages to update websetup.py as
nessisary, and the people reading the python magazine article can use
code that just works.
And from my perspective the code inside the quickstart--that we intend
for people to use and modify is part of our features, and this as a
new feature should have been covered by the feature freeze. All this
talk about API changes, public API changes, etc is besides the point.
This is a new feature, and so should be covered by the feature freeze.
But I take responsibility, this whole thing is my fault, because I
told Chris to go ahead without thinking through the consequences. I
made a mistake, and I totally take responsibility for that.
I think the sky will not fall either way, and I am definitely one of
the ones who wanted the functionality, but I also want the python
magazine article to give people a positive view of TG2.
Either choice was going to cause some people problems, and solve other
problems, so we were never going to have everybody happy, heck we were
never going to make me happy, because I want two conflicting things ;)
So, with all that said, let's not fight about what constitutes and API
change, and let's throw any stones than need throwing my direction.
I'm a pretty good catch, and if not I can take it.
Thanks!