Sorry for being so short. If you have any specific questions about how
to upgrade I'll be glad to answer them. I do think all pyramid_sqla
apps should be moved to Akhet by creating a new app and pasting your
code. That way we'll have one single structure going forward.
According to the changelog, the differences are:
- Name change, affecting the module name, and the metadata defined in setup.py.
- urlgenerator module is new.
- 'url' was previously aliased to 'pyramid.url.route_url'. Chrism did
that for preliminary Pylons compatibility. I didn't realize until
later that that meant you had to pass the request as the second
argument in every call.So i was going to change it to
'request.route_url', but then somebody sent me a class that became
URLGenerator, and I saw it as a more general solution.
- 'handlers' and 'models' are packages rather than single modules, to
facilitate larger applications
- 'lib' package created and 'helpers.py' moved into it, to match
Pylons and to give a place for non-helper extra code. Somebody was
putting things into helpers.py that I didn't think were helpers and
didn't belong under 'h'.
- You have to create the SQLAlchemy engines; add_engine() no longer
does it. It was supporting three different use cases with different
combinations of args (engine from settings, engine from explicit args,
and preexisting engine), and it was so hard to document how these
arguments interacted that I decided it was too much for one function.
Following the rule, "If it's hard to document, it's a bad design."
- Change "[app:{{projectname}}]" in INI file to hardcoded
"[app:myapp]". That's so you don't have to type the projectname in
MixedCase every time you start pshell or another command-line tool.
When you're developing several projects, it's easy to forget now this
one is named and whether to use the ProjetName (mixed case) or package
name (lower case). In Pylons you didn't need this arg because the app
was always "main". Somebody on IRC complained that hardcoding it to
"myapp" is a limitation, but to me it's a convenience for command-line
scripts and I don't see a downside. Actually, I now think it would be
best for PasteDeploy loadapp() to read all the sections and guess the
name, because there's only one 'app' section, and it can start by
assuming 'main' and then fall back to 'myapp', and abort if there are
multiple 'app' sections. Because very few people have multiple 'app'
sections. But that would require changing PasteDeploy. There is a move
afoot to replace PasteDeploy/PasteScript/Paste with some thing(s)
newer, but that's not soon enough for this.
- Switch to 'pyramid_tm' transaction manager from 'repoze.tm2'. The
latter is new; I chose it because it's not a middleware, which makes
the INI file less distorted. (I'm already unhappy that the need for a
pipeline in the INI file prevents us from using '[app:main]', thus
causing the previous problem.)
- 'akhet/testts/make_test_app.sh' is a quick-and-dirty script to
create a test application and run it. This is a stopgap until a more
complete unittest library to create a virtualenv+app and test it is
available. (Although this would be very slow with all of Pyramid's
dependencies to install. I use a pip "download-cache" to mitigate
this, but it still checks the latest versions on PyPI.)
On Sat, Mar 19, 2011 at 7:22 PM, Mike Orr <[email protected]> wrote:
> I was going to write an upgrading blurb but I'm too tired now. I've
> been up late for the past two days. The main difference is where
> things are imported from. There are also a bunch of tweaks in the app
> skeleton. I would create a new app and paste your code into it rather
> than trying to upgrade a pyramid_sqla app. There are too many name
> changes throughout the metadata files.
>
> On Sat, Mar 19, 2011 at 4:08 PM, Eric Ongerth <[email protected]> wrote:
>> Mike, thanks for all your hard work on this!
>>
>> I've been using pyramid_sqla for about a month with good results. I
>> suppose I should move over to Akhet; can you briefly summarize what
>> would change? From reading the docs it doesn't look like much, except
>> that SQLA was spun off, but I'd like to be sure I'm not missing
>> anything. I haven't been using WebHelpers so I'm not affected by any
>> changes in that department (except that I'm going to start making use
>> of paginate now that it's ready for Pyramid).
>>
>> - Eric
>>
>>
>> On Mar 19, 2:22 pm, Mike Orr <[email protected]> wrote:
>>> Akhet 1.0b1 is released. It's an application template for Pyramid
>>> that's closer to Pylons 1 than the ones that are built into Pyramid.
>>> It has extensive documentation covering the differences between Pylons
>>> and Pyramid, and can serve as a gentle introduction to the Pyramid
>>> manual. Version 1.0b1 is a beta test before the final release.
>>>
>>> Akhet is the successor of "pyramid_sqla" and the Pyramid Migration
>>> Guide. The SQLAlchemy library itself was spun off to a separate
>>> distribution SQLAHelper, which is framework-independent. Also released
>>> recently, WebHelpers 1.3b1, whose paginate has some URL generation
>>> classes for Pyramid.
>>>
>>> PyPI: http://pypi.python.org/pypi/Akhet
>>> Docs: http://sluggo.scrapping.cc/python/Akhet/
>>> Source:https://bitbucket.org/sluggo/akhet(Mercurial)
>>>
>>> The repositories will be moved to GitHub soonish but not immediately.
>>>
>>> --
>>> Mike Orr <[email protected]>
>>
>> --
>> 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.
>>
>>
>
>
>
> --
> Mike Orr <[email protected]>
>
--
Mike Orr <[email protected]>
--
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.
