Maybe a little off-topic, but the first idea springing to my mind when I read about converting Genshi templates into something else is "Why not go all the way to front-end development?"
Of course, it would be more work than just migrating to a classic Pyramid app (although the Python part would become much simpler, as complexity is off-loaded to the front-end app), but it's certainly worth it in the end. Personally, I have transitioned to back-end/front-end dev over a few years, it was sometimes tough, but it's done and I'm not looking back :) - 2 Python packages for the back-end (one "core", which can be shared between all projects, and one "custom"). Pyramid's ability for extending apps is precious here. - 2 Next.js/React packages for the front-end (one "core", one "custom" - with Yarn workspaces to link the two) - Ansible scripts to simplify management (deployment, sync db between production/staging/dev sites, ...), as the new architecture is more complex Just my 2 (Canadian) cents :) Laurent. Le mar. 1 avr. 2025 à 16:22, Ian Wilson <[email protected]> a écrit : > Pretty impressive it is still working. Is the codebase still using Python > 2? > > The last page of the document that Mike linked seems like the best > starting point: > https://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/pylons/migrate.html > > I guess it also depends on how many resources you have, how big the code > base is and how much downtime is allowable. > > A while ago I moved a PHP project into pyramid by running them behind a > proxy and moving route by route, or sometimes a subsystem at a time and > that went better than expected and was pretty flexible. Some work had to > be done beforehand to make sure both systems were using the sessions, > cookie-based, the same way and that the database clients, mysql, were > configured the same way, etc. Sounds complicated but I think you can > create a docker-compose setup with nginx+database+app1+app2 set up without > doing anything too crazy. Then just start chunking away at it and still > have both systems constantly "runnable" and not half-broken. > > Also if you could convert the templates last I would try to do that. I > think Genshi itself is still used by some projects so even if that adapter, > `pyramid_genshi`, is out of date you could potentially fix it and keep your > templates as-is and just find/simulate and inject any objects that were > expected to exist within the templates, ie. > https://docs.pylonsproject.org/projects/pylons-webframework/en/latest/modules/templating.html#template-globals > Writing a custom renderer isn't too bad: > https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/renderers.html#adding-a-new-renderer > Then you could come back and convert those templates to something else if > it was necessary without falling into a total rewrite. > > Just me 2 cents. > > Sounds kind of exciting to be honest. > > On Tue, Apr 1, 2025 at 5:29 AM Mike Orr <[email protected]> wrote: > >> Here's the information the Pylons developers and core users at the >> time used to migrate their applications to Pyramid. >> >> https://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/pylons/index.html >> (Pyramid Cookbook, section "Pyramid for Pylons Users", written by me) >> That was in 2012. I migrated my applications later when work resources >> allowed, in 2017 and 2020. It was so long ago I'm afraid I don't >> remember what Pylons code looks like, or what Genshi was like. We also >> made the migration under Python 2, and some of the older tools were >> never ported to Python 3. >> >> I'd use the guide as background information to understand Pyramid, and >> how certain Pylons features relate to their closest Pyramid >> counterparts. I wouldn't use the specific tools mentioned (akhet, >> pyramid_sqla) because they were never used much and may no longer >> work. If your application uses webhelpers, it has been replaced by >> webhelpers2, which has its own migration guide. >> >> Some developer tried to mimic the Pylons application structure as >> closely as possible in Pyramid; e.g., using a class for a group of >> controllers, but the first real applications to be ported found it >> better to switch to the native Pyramid paradigm rather than trying to >> recreate a Pylons-like structure, so later conversions also followed >> that approach (including mine). So I'd try to rethink your >> application's functionality in a native Pyramid paradigm, rather than >> trying to replicate a Pylons-like structure. When you can identify >> more specific problems (e.g., how to migrate something in a Pylons >> controller, or a specific route feature or temilating feature), then >> we may be able to help more with those. >> >> Pylons controllers were classes that grouped several view methods >> together. I would port each view separately, as either a function or >> class (your choice). If you go the class way, you can have a base >> class for common functionality. The simplest base class is: >> >> ``` >> class View: >> def ___init__(self, request): >> self.request = request >> ``` >> >> If you go the function way, you'd put common functionality in utility >> functions. >> >> There is a Genshi template adapter for Pyramid, 'pyramid_genshi'. I >> don't know of anybody who has used it, or whether it still works. Most >> Pylons developers migrated to Mako. Jinja2 and Chameleon get some use. >> >> There's no way to reuse existing routes, globals, and application >> setup, because those are the things that changed the most in Pyramid. >> Pylons had a number of "magic" globals that you imported, and the >> value was local to the current request. So you didn't have to pass >> those around between functions; you could just import them in each >> one. Pylons applications used these extensively, but they proved to be >> fragile and to break easily. So most applications migrating to Pyramid >> switched to explicit argument passing to eliminate the magic. That's a >> large part of why you can't just use globals and setup code in Pyramid >> the same way as in Python, and why WebHelpers2 had to restructure or >> drop many helpers that WebHelpers had. Pyramid does have a few >> "threadlocals" under the hood, but it's not recommended to use those >> directly. Most of what in Pylons you'd import a magic global for, in >> Pyramid you'd use the 'request' object. >> >> The 'request' object is implicitly passed to templates in case it's >> needed for this. E.g., Pyramid's 'request.route_path()' replaces >> Pylons' magic 'url()' function. (It wasn't really a function, but >> that's how it was used.) You can call that in the tempate, or >> precalcuate the URLs in the views and pass them as template variables. >> I've grown to prefer the latter, so that if an exception occurs, it >> occurs in static Python code in your repository rather than in a >> generated Python template module. >> >> I'd follow one of the Pyramid tutorials to create a basic application, >> and then try to add one view or feature from your application at a >> time. >> >> On Tue, Apr 1, 2025 at 3:48 AM Milan Kelesi <[email protected]> wrote: >> > >> > Hello, >> > >> > We are planning to migrate an existing project from Pylons 1.0.2 to >> Pyramid 2.x. >> > What would be the best approach to start? >> > I understand we need to rewrite all the controllers. >> > We are using Genshi templates and this does not seem to be supported in >> Pyramid 2. What would be the easiest template engine to migrate to from >> Genshi (Mako, Jinja2, Chameleon, ..) >> > Is there an easy way to reuse the existing routes, globals, application >> setup? >> > I am currently a bit overwhelmed and not sure where to start. >> > I would like to get a quick win and get one simple route/controller >> without authentication to work under pyramid. >> > >> > Thanks for any advice. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "pylons-discuss" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to [email protected]. >> > To view this discussion visit >> https://groups.google.com/d/msgid/pylons-discuss/5e27e69c-f7b6-47ed-917a-8c66d0537c4dn%40googlegroups.com >> . >> >> >> >> -- >> Mike Orr <[email protected]> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/pylons-discuss/CAH9f%3DuoB7PmEdq4LNkw7pOJ-B4ryr0ebuADfv8oJW17jJstsOQ%40mail.gmail.com >> . >> > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/pylons-discuss/CADj1%3D67TyKEGcWopejXqiOiSDiRTF2kUs6_%2B%3Duq8CKVJbDMiPA%40mail.gmail.com > <https://groups.google.com/d/msgid/pylons-discuss/CADj1%3D67TyKEGcWopejXqiOiSDiRTF2kUs6_%2B%3Duq8CKVJbDMiPA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/pylons-discuss/CAB7cU6zjAkxh_2%3DJL7JUjQX720%2BaiV97cS8%3DBkgCmJYJrfo0xQ%40mail.gmail.com.
