Re: [pylons-discuss] Migrating from Pylons 1.0.2
I actually just now found the BeforeRender event, which seems to be what we need :) Thanks, Milan On Friday, June 6, 2025 at 8:39:55 AM UTC+2 Florian Schulze wrote: > > 2. We have some variables that were set in Pylons as globals and are used > > almost in all templates. > > What is the best way to add these variables to all views or a subset of > > views without explicitly adding them to every view ? I was looking at > > tweens or just creating a base class from which the view classes would > > descend and would inject the variables in returned dictionary. > > Maybe there is a better way? > > You can inject variables into the renderer: > > https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/narr/hooks.html#using-the-before-render-event > > Or add a method/property to requests: > > https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/api/config.html#pyramid.config.Configurator.add_request_method > > There might be other more appropriate methods using other events or hooks > depending on your use cases. > > Regards, > Florian > -- 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/78ee24a9-b5b4-48d5-9bb3-58bc872ed022n%40googlegroups.com.
Re: [pylons-discuss] Migrating from Pylons 1.0.2
> 2. We have some variables that were set in Pylons as globals and are used > almost in all templates. > What is the best way to add these variables to all views or a subset of > views without explicitly adding them to every view ? I was looking at > tweens or just creating a base class from which the view classes would > descend and would inject the variables in returned dictionary. > Maybe there is a better way? You can inject variables into the renderer: https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/narr/hooks.html#using-the-before-render-event Or add a method/property to requests: https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/api/config.html#pyramid.config.Configurator.add_request_method There might be other more appropriate methods using other events or hooks depending on your use cases. Regards, Florian -- 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/BF99B5E2-5F30-4410-88CC-7F16EECA375E%40florian-schulze.net.
Re: [pylons-discuss] Migrating from Pylons 1.0.2
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 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
Re: [pylons-discuss] Migrating from Pylons 1.0.2
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 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 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: >>
Re: [pylons-discuss] Migrating from Pylons 1.0.2
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 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.
