On Sat, Jun 5, 2010 at 12:57 AM, daniel <[email protected]> wrote: > I wish thanking you for this piece of history about pylons, which I > really appreciate because it helps in getting a better understanding > of the full picture. I personally think it is always good > transparently sharing background, reasons of choices, pros and cons > about a topic.
Here's the full history. I see it hasn't been updated since 2008, but it covers the early years. http://wiki.pylonshq.com/display/pylonscommunity/Pylons+Historical+Timeline Other bits about the Pylons community and marketing plans, all out of date probably, are in the Pylons Community section of the wiki. http://wiki.pylonshq.com/display/pylonscommunity/Home > Also I like your suggestion for a clear statement about phased-out > packages (authkit in this case or maybe others). It would give to new > pylons adopters a safe feeling, which is not the case when they > discover the obsolescence of a package through posted comments. I changed the main auth page and deleted the AuthKit pages in the Cookbook. They mostly referred to the section in the Pylons book or elaborated it. So those who see it in the book will get the author's advice, and those who don't find that chapter needn't worry about it. There are 18 pages of other references to it in the wiki but it would take way too long to go looking all those up and posting warning messages. We need to promote the main auth page as much as possible. http://wiki.pylonshq.com/display/pylonscookbook/Authentication+and+Authorization I don't know how many new users realize that the Pylons Cookbook section in the wiki is the place for unofficial documentation, and that the pages listed on the main page or underneath portal pages like the auth page are most likely to have the most up-to-date advice. (But unfortunately it's not all up to date, and we need to give the wiki a good spring cleaning, but nobody has time to. I find it easier to just answer questions on the list. > So to my view the second rule in marketing pylons (the first is in > line with what you say are already doing: write good code with long > term in mind) is to make clear, transparent and frequent > communications on both bad and good recommendations, so that pylons > adopters feel always comfortable. The fact that pylons allows for > choosing from a broad range of solutions does not contrast with giving > a structured information about past good and bad experiences. If > authkit has not fitted most of the last pylons experiences, it should > be said in a clear and strong manner, because it is beneficial to > pylons users, especially to pylons newcomers. For instance I ended to > the conclusion of using instead repoze.who/what after a week of > googling and pylons-discuss, it could have been a matter of a few > minutes if it were clearly recommended on pylons site Well, i think the developers didn't want to disrespect James because he was a founder and AuthKit was his creation. Certainly there were users who took it into their hands to steer people away from AuthKit. I kept reminding James that if he was going to promote AuthKit, he needed to support it. I think he finally gave up combating all its negative publicity and just abandoned it himself. I wish he'd made a more definitive disavowal of it, then we could have taken it off the recommended list a while ago. As for other components that may be in similar circumstances, you bring up a good point. I can't think of any other packages that are similarly unlucky. At least none that anybody's using nowadays. I trust nobody's using Pylons 0.9.5 anymore and the last people are getting off 0.9.6. I myself am very happy with Mako, and my SQLAlchemy 0.6 upgrade has been just fine after changing a few deprecated usages. Repoze.who/what looks quite extensive but I find it a bit difficult to keep track of all the parts. I finally ended up making my own demonstration site step by step following the various tutorials and application templates. But I needed to do a hybrid form of LDAP+database auth that didn't really fit with who's structure, and then I discovered the repoze.who-LDAP module is unmaintained. I think if I go back to who/what I'll write my own identity plugin (if that's the right term) rather than trying to shoehorn my needs into the existing LDAP, SQLAlchemy, and identity-properties plugins. But my needs are rather specific and unusual. I haven't used ToscaWidgets or FormAlchemy or its descendants but they seem capable and well-supported. TW has always been lacking in the documentation area; I don't know if that's been remedied, but I did take a great tutorial in it at PyCon by Chris Perkins who's a TW guru, and it seems quite powerful, though it is rather complex to understand and do you really want all those dependencies? Or rather, how central are generated forms to your application? So far I haven't needed them. I'm sure you've noticed FormEncode docs aren't very clear and I finally, *finally* , have time to work on a manual for it, yippee. > I've been in electronic products marketing for more or less the last > 20 years and I'd be glad helping one day in some way in marketing > pylons as soon as I reach myself a decent technical knowledge about > pylons (i.e. go through a few pylons based projects) That would be great. If you see a niche you can fill, or a suggestion to make, please feel free. -- 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.
