I put in a summary of what should be in them, and I'd be happy to help with proof reading, etc. for anyone that wants to take a crack at these two.
At this point, Pylons 1.0 and 0.10 are stable and I think WebHelpers is close to being ready for a 1.0 release as well. While there's some minor tickets in Beaker/Routes, I don't see anything that warrants holding back a Pylons 1.0 release.
How to Help
==========
To work on these tickets, please indicate that on the ticket, and assign it to yourself, then:
1) Fork the project on Bitbucket: http://bitbucket.org/bbangert/pylons/ 2) Check out your fork
3) Apply your fixes to the documentation, and push your changes back
4) Send a pull request on BitBucket
Other ways to help (fixes should be done the same as above):
- Proof-read the existing documentation
- Test the documentation against Pylons 1.0 to ensure it actually works (Installing Pylons 1.0: http://pylonshq.com/docs/en/1.0/gettingstarted/#installing)
- Ensure the QuickWiki works against Pylons 1.0 (I believe Graham has updated the code for it recently, it'd be great to have some ppl test it)
Also, I know some people have asked and are curious about what future changes are planned for Pylons post-1.0, so I'll be writing up a blog post in the next few days outlining a rough future roadmap for where Pylons is going, and what new features are planned.
Cheers,
Ben Bangert
-- You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
> You, (Yes, You!), can help get Pylons 1.0 out the door sooner. So
> what's holding up the release at this point?
> Two documentation tickets:
> While there's some minor tickets in Beaker/Routes, I don't see
> anything that warrants holding back a Pylons 1.0 release.
Trac seems to be lagging slightly (and is due a light spam weeding) ...
* #679 has been fixed
* #685 (Can't create a site named 'Site') is apparently a Paster issue
* #688 (newline in signed cookie) seems still to be extant
> - Ensure the QuickWiki works against Pylons 1.0 (I believe Graham
> has updated the code for it recently, it'd be great to have some ppl
> test it)
-- You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
I don't think I can help write either of the docs mentioned but I too
would be very happy to do some proofreading. When you're ready, drop
me an email or a tweet (I'm @asplake) and I should be able to turn it
around in a day or two. I have also fixed a few issues with tests
under Windows; if anyone needs tests run there, give me a shout.
Would it be premature to discuss what comes afterwards? Validation
must come high on the list, and my guess is that the work involved
will be not so much about Pylons code - that will be the easy bit once
we're happy with patterns to recommend for application code (I
hesitate to limit it to just controller code). JSON and AJAX fit in
there somewhere too.
Anything else in the pipeline to look forward to?
But while I'm here, let me say thank you! Though a risk, going for
Pylons well before 1.0 has definitely been a good decision; now
looking forward to it hitting that milestone.
Mike
On May 19, 2:59 am, Ben Bangert <b...@groovie.org> wrote:
> I put in a summary of what should be in them, and I'd be happy to help with proof reading, etc. for anyone that wants to take a crack at these two.
> At this point, Pylons 1.0 and 0.10 are stable and I think WebHelpers is close to being ready for a 1.0 release as well. While there's some minor tickets in Beaker/Routes, I don't see anything that warrants holding back a Pylons 1.0 release.
> How to Help
> ==========
> To work on these tickets, please indicate that on the ticket, and assign it to yourself, then:
> 1) Fork the project on Bitbucket:http://bitbucket.org/bbangert/pylons/ > 2) Check out your fork
> 3) Apply your fixes to the documentation, and push your changes back
> 4) Send a pull request on BitBucket
> Other ways to help (fixes should be done the same as above):
> - Proof-read the existing documentation
> - Test the documentation against Pylons 1.0 to ensure it actually works (Installing Pylons 1.0:http://pylonshq.com/docs/en/1.0/gettingstarted/#installing)
> - Ensure the QuickWiki works against Pylons 1.0 (I believe Graham has updated the code for it recently, it'd be great to have some ppl test it)
> Also, I know some people have asked and are curious about what future changes are planned for Pylons post-1.0, so I'll be writing up a blog post in the next few days outlining a rough future roadmap for where Pylons is going, and what new features are planned.
> Cheers,
> Ben Bangert
> --
> You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group athttp://groups.google.com/group/pylons-discuss?hl=en.
-- You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
I'll throw in my proof-reading offer as well, send it my way and I'll run
through it as soon as possible. But I am just getting started with Pylons
and don't have the experience to tackle writing either of these docs,
unfortunately.
On Wed, May 19, 2010 at 7:55 AM, Mike Burrows <m...@asplake.co.uk> wrote:
> Hi Ben (and all),
> I don't think I can help write either of the docs mentioned but I too
> would be very happy to do some proofreading. When you're ready, drop
> me an email or a tweet (I'm @asplake) and I should be able to turn it
> around in a day or two. I have also fixed a few issues with tests
> under Windows; if anyone needs tests run there, give me a shout.
> Would it be premature to discuss what comes afterwards? Validation
> must come high on the list, and my guess is that the work involved
> will be not so much about Pylons code - that will be the easy bit once
> we're happy with patterns to recommend for application code (I
> hesitate to limit it to just controller code). JSON and AJAX fit in
> there somewhere too.
> Anything else in the pipeline to look forward to?
> But while I'm here, let me say thank you! Though a risk, going for
> Pylons well before 1.0 has definitely been a good decision; now
> looking forward to it hitting that milestone.
> Mike
> On May 19, 2:59 am, Ben Bangert <b...@groovie.org> wrote:
> > You, (Yes, You!), can help get Pylons 1.0 out the door sooner. So what's
> holding up the release at this point?
> > I put in a summary of what should be in them, and I'd be happy to help
> with proof reading, etc. for anyone that wants to take a crack at these two.
> > At this point, Pylons 1.0 and 0.10 are stable and I think WebHelpers is
> close to being ready for a 1.0 release as well. While there's some minor
> tickets in Beaker/Routes, I don't see anything that warrants holding back a
> Pylons 1.0 release.
> > How to Help
> > ==========
> > To work on these tickets, please indicate that on the ticket, and assign
> it to yourself, then:
> > 1) Fork the project on Bitbucket:http://bitbucket.org/bbangert/pylons/ > > 2) Check out your fork
> > 3) Apply your fixes to the documentation, and push your changes back
> > 4) Send a pull request on BitBucket
> > Other ways to help (fixes should be done the same as above):
> > - Proof-read the existing documentation
> > - Test the documentation against Pylons 1.0 to ensure it actually works
> (Installing Pylons 1.0:
> http://pylonshq.com/docs/en/1.0/gettingstarted/#installing)
> > - Ensure the QuickWiki works against Pylons 1.0 (I believe Graham has
> updated the code for it recently, it'd be great to have some ppl test it)
> > Also, I know some people have asked and are curious about what future
> changes are planned for Pylons post-1.0, so I'll be writing up a blog post
> in the next few days outlining a rough future roadmap for where Pylons is
> going, and what new features are planned.
> > Cheers,
> > Ben Bangert
> > --
> > You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> > To post to this group, send email to pylons-discuss@googlegroups.com.
> > To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com<pylons-discuss%2Bunsubscribe@go oglegroups.com>
> .
> > For more options, visit this group athttp://
> groups.google.com/group/pylons-discuss?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com<pylons-discuss%2Bunsubscribe@go oglegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
-- You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
I like Pylons but 40 years in IT has left me unable to help competently. I can pick up part of a bar tab though, if you guys ever get together, after proof reading of course.
Thanks for your efforts in putting together a great tool, Clemens Herschel
Ryan Arana wrote:
> I'll throw in my proof-reading offer as well, send it my way and I'll > run through it as soon as possible. But I am just getting started with > Pylons and don't have the experience to tackle writing either of these > docs, unfortunately.
> On Wed, May 19, 2010 at 7:55 AM, Mike Burrows <m...@asplake.co.uk > <mailto:m...@asplake.co.uk>> wrote:
> Hi Ben (and all),
> I don't think I can help write either of the docs mentioned but I too
> would be very happy to do some proofreading. When you're ready, drop
> me an email or a tweet (I'm @asplake) and I should be able to turn it
> around in a day or two. I have also fixed a few issues with tests
> under Windows; if anyone needs tests run there, give me a shout.
> Would it be premature to discuss what comes afterwards? Validation
> must come high on the list, and my guess is that the work involved
> will be not so much about Pylons code - that will be the easy bit once
> we're happy with patterns to recommend for application code (I
> hesitate to limit it to just controller code). JSON and AJAX fit in
> there somewhere too.
> Anything else in the pipeline to look forward to?
> But while I'm here, let me say thank you! Though a risk, going for
> Pylons well before 1.0 has definitely been a good decision; now
> looking forward to it hitting that milestone.
> Mike
> On May 19, 2:59 am, Ben Bangert <b...@groovie.org
> <mailto:b...@groovie.org>> wrote:
> > You, (Yes, You!), can help get Pylons 1.0 out the door sooner.
> So what's holding up the release at this point?
> > I put in a summary of what should be in them, and I'd be happy
> to help with proof reading, etc. for anyone that wants to take a
> crack at these two.
> > At this point, Pylons 1.0 and 0.10 are stable and I think
> WebHelpers is close to being ready for a 1.0 release as well.
> While there's some minor tickets in Beaker/Routes, I don't see
> anything that warrants holding back a Pylons 1.0 release.
> > How to Help
> > ==========
> > To work on these tickets, please indicate that on the ticket,
> and assign it to yourself, then:
> > 1) Fork the project on
> Bitbucket:http://bitbucket.org/bbangert/pylons/ > > 2) Check out your fork
> > 3) Apply your fixes to the documentation, and push your changes back
> > 4) Send a pull request on BitBucket
> > Other ways to help (fixes should be done the same as above):
> > - Proof-read the existing documentation
> > - Test the documentation against Pylons 1.0 to ensure it
> actually works (Installing Pylons
> 1.0:http://pylonshq.com/docs/en/1.0/gettingstarted/#installing)
> > - Ensure the QuickWiki works against Pylons 1.0 (I believe
> Graham has updated the code for it recently, it'd be great to have
> some ppl test it)
> > Also, I know some people have asked and are curious about what
> future changes are planned for Pylons post-1.0, so I'll be writing
> up a blog post in the next few days outlining a rough future
> roadmap for where Pylons is going, and what new features are planned.
> > Cheers,
> > Ben Bangert
> > --
> > You received this message because you are subscribed to the
> Google Groups "pylons-discuss" group.
> > To post to this group, send email to
> pylons-discuss@googlegroups.com
> <mailto:pylons-discuss@googlegroups.com>.
> > To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com
> <mailto:pylons-discuss%2Bunsubscribe@googlegroups.com>.
> > For more options, visit this group
> athttp://groups.google.com/group/pylons-discuss?hl=en > <http://groups.google.com/group/pylons-discuss?hl=en>.
> --
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To post to this group, send email to
> pylons-discuss@googlegroups.com
> <mailto:pylons-discuss@googlegroups.com>.
> To unsubscribe from this group, send email to
> pylons-discuss+unsubscribe@googlegroups.com
> <mailto:pylons-discuss%2Bunsubscribe@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
> -- > You received this message because you are subscribed to the Google > Groups "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
-- You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
> And I'm not at all sure that, in the interests of longer-term > stability, "SQLAlchemy>=0.5" oughtn't to be something like > "SQLAlchemy>=0.5,<=0.6".
I've spent several hours to put Pylons 0.9.7 to work after update to ... version 0.9.7 (within a few months). The root cause was in IMNHO wrong dependency with some libraries (WebHelpers in this case). IMHO there should be added min and max valid version of library on dependency list.
On Tue, May 25, 2010 at 3:03 PM, artee <artur....@gmail.com> wrote: >> And I'm not at all sure that, in the interests of longer-term >> stability, "SQLAlchemy>=0.5" oughtn't to be something like >> "SQLAlchemy>=0.5,<=0.6". > I've spent several hours to put Pylons 0.9.7 to work after update > to ... version 0.9.7 (within a few months). > The root cause was in IMNHO wrong dependency with some libraries > (WebHelpers in this case). > IMHO there should be added min and max valid version of library on > dependency list.
What's the issue with WebHelpers? The Pylons dependency is 'WebHelpers>=0.6.4' because it can work with either 0.6.4 or the 1.x series. Applications that depend on the Rails helpers will have to fix themselves to 'WebHelpers==0.6.4'. Applications that depend on new features will have to set the minimum to whenever that feature was introduced. We can't restrict the Pylons dependency without causing conflicts: Paster refusing to start because the Pylons restriction and the application restriction don't overlap.
The same issue applies to SQLAlchemy. If you restrict SQLAlchemy to the 0.5 series, then applications that want to use 0.6 will have to modify other packages' setup.py in order to run, and this patch would have to be reapplied by hand whenever the other packages are updated.
My reasoning is that the lack of an upper limit seems to imply an unwarranted assumption that arbitrary future SQLA releases will be back-compatible with Pylons project templates written for SQLA 0.5 (or, in extremis, 0.6) releases.
I'm wondering whether "SQLAlchemy>=0.5" isn't actually a needless and potentially troublesome imprecision that would be trivial to correct at this stage of the game.
From the peanut gallery, I agree with Graham. I feel like a specific version of software should mean everything, including packages it depends on, are locked. If a new package it uses gets updated, then it becomes a new version.
On Tue, May 25, 2010 at 9:39 PM, Graham Higgins <gjhigg...@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> On 25 May 2010, at 23:19, Mike Orr wrote:
>> If you restrict SQLAlchemy to the 0.5 series
> I think you misread this:
>> something like "SQLAlchemy>=0.5,<=0.6"
> My reasoning is that the lack of an upper limit seems to imply an > unwarranted assumption that arbitrary future SQLA releases will be > back-compatible with Pylons project templates written for SQLA 0.5 (or, in > extremis, 0.6) releases.
> I'm wondering whether "SQLAlchemy>=0.5" isn't actually a needless and > potentially troublesome imprecision that would be trivial to correct at this > stage of the game.
> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
Ah, talking of needlessly imprecise --- SQLA current is 0.6.0. I was too casual, prolly misled you as to my intention (which was to cover the range of 0.5 and 0.6).
I like the needless precision myself :) In fact, about a year ago, I mentioned, I even liked the idea of having all the components available in a bundle like an OS X application.
On Tue, May 25, 2010 at 9:57 PM, Graham Higgins <gjhigg...@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1
> On 26 May 2010, at 05:39, Graham Higgins wrote:
>> I think you misread this:
>>> something like "SQLAlchemy>=0.5,<=0.6"
> Ah, talking of needlessly imprecise --- SQLA current is 0.6.0. I was too > casual, prolly misled you as to my intention (which was to cover the range > of 0.5 and 0.6).
> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
> What's the issue with WebHelpers? The Pylons dependency is
I don't remember details because it was a few months ago but it was related to url_for helper and new pylons implementation (url class). The same project, the same Pylons 0.9.7 but WebHelpers was changed significantly. Anyway, because Pylons consists of several external libraries it would be a good idea to add more strict version checking. Using Pylons 0.9.7 in 2009 and 2010 should give us the same results :)
> The same issue applies to SQLAlchemy. If you restrict SQLAlchemy to > the 0.5 series, then applications that want to use 0.6 will have to
I agree with you but SA is a separate package and Pylons can live without it. Without Webhelpers? No way ;)
On May 26, 1:05 am, artee <artur....@gmail.com> wrote:
> > What's the issue with WebHelpers? The Pylons dependency is
> I don't remember details because it was a few months ago but it was > related to url_for helper and new pylons implementation (url class). > The same project, the same Pylons 0.9.7 but WebHelpers was changed > significantly. > Anyway, because Pylons consists of several external libraries
Sorry to be contrary, but I think this statement is somewhat incorrect. A typical Pylons-based projects--created via `paster create`--makes use of certain packages/libraries (by default), but Pylons itself doesn't necessarily depend on those packages--*your project* does. More below...
> it would > be a good idea to add more strict version checking. > Using Pylons 0.9.7 in 2009 and 2010 should give us the same results :)
> > The same issue applies to SQLAlchemy. If you restrict SQLAlchemy to > > the 0.5 series, then applications that want to use 0.6 will have to
> I agree with you but SA is a separate package and Pylons can live > without it. > Without Webhelpers? No way ;)
Not every Pylons-based app needs WebHelpers. For example, I have a web services package that renders only JSON, so there are no templates, no public files, no helpers, etc. I'm not sure whether Pylons uses WebHelpers internally (sorry, can't grep from here). If not, I'd say that the dependency should be *removed* from Pylons itself (i.e., from its setup.py) and let application developers decide whether they need it (though it could still be part of the default template when using `paster create`).
The same thing is true of, for example, Routes. Pylons doesn't strictly depend on Routes (as far as I know); it depends on certain values being present in the environ. If I decide to swap Routes for something else, I don't want to be forced to download and install Routes. This could be handled with the `paster create` template, too-- the default dependencies would be injected into the new project's setup.py (right now, the template only has the Pylons dependency in its setup.py).
As it is now, it seems that Pylons is using really low version numbers to make sure that if you "override" package versions in your project's setup.py, there's not a conflict. I don't know if it's the best approach or not, but so far, it hasn't caused me any problems, but I think this is mainly because I add all the Pylons-related dependencies to my setup.py.
So, a proposal for Pylons 1.1 or later: remove all deps from Pylons' setup.py that are not used directly by Pylons. Add those deps instead to projects created by `paster create`. I haven't completely thought this through, so I don't no what all the ramifications might be. Thoughts?
Noah Gift wrote: > I like the needless precision myself :) In fact, about a year ago, I > mentioned, I even liked the idea of having all the components > available in a bundle like an OS X application.
> On Tue, May 25, 2010 at 9:57 PM, Graham Higgins <gjhiggins-Re5JQEeQqe8AvxtiuMw...@public.gmane.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1
>> On 26 May 2010, at 05:39, Graham Higgins wrote:
>>> I think you misread this:
>>>> something like "SQLAlchemy>=0.5,<=0.6"
>> Ah, talking of needlessly imprecise --- SQLA current is 0.6.0. I was too >> casual, prolly misled you as to my intention (which was to cover the range >> of 0.5 and 0.6).
>> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To post to this group, send email to pylons-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZC...@public.gmane.org >> To unsubscribe from this group, send email to >> pylons-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZC...@public.gmane.org >> For more options, visit this group at >> http://groups.google.com/group/pylons-discuss?hl=en.
On May 26, 8:06 am, Wyatt Baldwin <wyatt.lee.bald...@gmail.com> wrote:
> [...]
> So, a proposal for Pylons 1.1 or later: remove all deps from Pylons' > setup.py that are not used directly by Pylons.
In case anyone's interested, these are the dependencies in the Pylons source (excluding stdlib):
decorator formencode nose paste paste.deploy paste.script pkg_resources (could almost be considered part of stdlib) simplejson tempita weberror webhelpers webob
Total: 12 (or 11 if you don't include pkg_resources)
Methodology (admittedly a little sloppy):
- cd to Pylons egg directory in site-packages - find . -name '*.py' | grep -v ez_setup.py | xargs egrep -h '^(import| from)' | grep -v pylons | sort | uniq > ~/pylons-imports - use vim search-and-replace to get just the package name - manually prune stdlib lines
And here are the dependencies listed in Pylons' setup.py:
Beaker (move to project template?) decorator FormEncode Mako (move to project template?) nose (move to test_requires, so users aren't forced to install?) Paste PasteDeploy PasteScript Routes (move to project template?) simplejson (detect user's Python version and only include this if needed?) Tempita WebError WebHelpers WebOb WebTest
Total: 15
In the end, a few opportunities for decoupling; not as many as I would have thought, but perhaps more is possible without too much effort. Devs: if there's interest, I'll submit a ticket and work on a patch.
On Wed, May 26, 2010 at 8:52 AM, whit <w...@surveymonkey.com> wrote:
> Noah Gift wrote:
>> I like the needless precision myself :) In fact, about a year ago, I >> mentioned, I even liked the idea of having all the components >> available in a bundle like an OS X application.
> provide pylons as a pip pybundle?
I think that would be a good idea. Most companies that deal with compiled software have a build and deploy system. I wish this was more common in Python. The "build" would simply be a bundle that runs a full continuous integration test on the sub components, and then the final product would be a bundle that is self enclosed and requires zero internet access.
>> On Tue, May 25, 2010 at 9:57 PM, Graham Higgins >> <gjhiggins-Re5JQEeQqe8AvxtiuMw...@public.gmane.org> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1
>>> On 26 May 2010, at 05:39, Graham Higgins wrote:
>>>> I think you misread this:
>>>>> something like "SQLAlchemy>=0.5,<=0.6"
>>> Ah, talking of needlessly imprecise --- SQLA current is 0.6.0. I was too >>> casual, prolly misled you as to my intention (which was to cover the >>> range >>> of 0.5 and 0.6).
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "pylons-discuss" group. >>> To post to this group, send email to >>> pylons-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZC...@public.gmane.org >>> To unsubscribe from this group, send email to
> -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en.
On Wed, May 26, 2010 at 1:05 AM, artee <artur....@gmail.com> wrote: >> What's the issue with WebHelpers? The Pylons dependency is > I don't remember details because it was a few months ago but it was > related to url_for helper and new pylons implementation (url class). > The same project, the same Pylons 0.9.7 but WebHelpers was changed > significantly. > Anyway, because Pylons consists of several external libraries it would > be a good idea to add more strict version checking. > Using Pylons 0.9.7 in 2009 and 2010 should give us the same results :)
It's impossible to predict what will be compatible with what in the future. There are problems with being too permissive in versions, but there are other problems with being too restrictive. It's really hard to troubleshoot a false restriction: Setuptools just says "unable to fulfill requirement SQLAlchemy>=0.5,<=0.6" or something like that, without telling you where the require() call is or which other packages are imposing the restriction. This is especially a pain for newbies, who don't understand enough about sys.path and the EGG-INFO files and setup.py to find the restriction and evaluate it.
So I come down on the side of, don't declare an incompatibility unless you're sure it's an incompatibility. The same applies with lower versions. If Pylons requires 'Routes>=1.12', it should have a good reason for disallowing 1.11 (i.e., it would break Pylons), and not simply that Routes 1.12 was the current version when Pylons X.X was released. Because maybe the user wants to stick with Routes 1.11 because 1.12 makes some undesired changes.
It's really up to the application to disallow versions it doesn't want, because a version that's fine for one application may not work for another. Also, people have both old and new applications. Old applications may need to stick with old libraries, while new applications want to use the latest. Pylons can't be both permissive and restrictive; it has to choose one or the other. Being permissive allows both cases to work. Being restrictive requires users to hack Pylons' setup.py to allow the newer version to be used -- and to reapply the hack whenever upgrading Pylons.
Pylons should probably include a 'requirements' file listing versions that are known to work with the release. The docs can tell people to install this if they want to be conservative, or regular Pylons if they want the latest of everything (and the potential disadvantages of doing so).
Then we should also encourage PYLONS APPLICATIONS to declare a 'requirements' file listing versions the application has been tested with.
>> The same issue applies to SQLAlchemy. If you restrict SQLAlchemy to >> the 0.5 series, then applications that want to use 0.6 will have to > I agree with you but SA is a separate package and Pylons can live > without it. > Without Webhelpers? No way ;)
Pylons itself depends on WebHelpers. The SQLAlchemy dependency is only in the application.
<wyatt.lee.bald...@gmail.com> wrote: > Not every Pylons-based app needs WebHelpers. For example, I have a web > services package that renders only JSON, so there are no templates, no > public files, no helpers, etc. I'm not sure whether Pylons uses > WebHelpers internally (sorry, can't grep from here). If not, I'd say > that the dependency should be *removed* from Pylons itself (i.e., from > its setup.py) and let application developers decide whether they need > it (though it could still be part of the default template when using > `paster create`).
> The same thing is true of, for example, Routes. Pylons doesn't > strictly depend on Routes (as far as I know); it depends on certain > values being present in the environ. If I decide to swap Routes for > something else, I don't want to be forced to download and install > Routes. This could be handled with the `paster create` template, too-- > the default dependencies would be injected into the new project's > setup.py (right now, the template only has the Pylons dependency in > its setup.py).
> So, a proposal for Pylons 1.1 or later: remove all deps from Pylons' > setup.py that are not used directly by Pylons. Add those deps instead > to projects created by `paster create`. I haven't completely thought > this through, so I don't no what all the ramifications might be. > Thoughts?
I tend to agree with this. It's too late to make such a far-reaching change in Pylons 1.0, but it's doable in 1.1. There are some inconveniences, however.
What we're seeing is a conflict between out-of-the-box simplicity for newbies, vs flexibility for advanced uses and compatibility for old applications.
Moving the dependencies to the application is more correct and more flexible, but it also means that "pip install Pylons" won't install a full stack. The only way around this is to have a separate "Pylons-minimal" and "Pylons-full" distribution. Perhaps the componentization with Marco will make this more desirable anyway.
As for Pylons' dependencies (this is off the top of my head and may not be 100% accurate):
- Beaker: optional (activated in middleware.py) - decorator: optional, required for ``pylons.decorator`` utilities - FormEncode: optional - Nose: optional, required for tests - Paste: required - PasteDeploy: required, Pylons uses some utilities internally (asbool) - PasteScript: required, for "paster create" etc. - Routes: required. (Strictly speaking, RoutesMiddleware or a compatible alternative is required) - simplejson: optional, required for ``pylons.decorator`` utilities. (Included in Python 2.6.) - Tempita: required by Paste - WebError: required? (May be deactivated in middleware.py?) - WebHelpers: optional - WebOb: required - WebTest: required? Required for tests.
On Wed, May 26, 2010 at 11:05 AM, Mike Orr <sluggos...@gmail.com> wrote: > As for Pylons' dependencies (this is off the top of my head and may > not be 100% accurate):
> - Beaker: optional (activated in middleware.py) > - decorator: optional, required for ``pylons.decorator`` utilities > - FormEncode: optional > - Nose: optional, required for tests > - Paste: required > - PasteDeploy: required, Pylons uses some utilities internally (asbool) > - PasteScript: required, for "paster create" etc. > - Routes: required. (Strictly speaking, RoutesMiddleware or a > compatible alternative is required) > - simplejson: optional, required for ``pylons.decorator`` utilities. > (Included in Python 2.6.) > - Tempita: required by Paste > - WebError: required? (May be deactivated in middleware.py?) > - WebHelpers: optional > - WebOb: required > - WebTest: required? Required for tests.
Moving all the optional dependencies to the application would cause Pylons to have some undeclared dependencies. For instance, ``pylons.decorator.*`` is not required for Pylons to run. But if somebody tries to use some of the utilities in it, they'll get an ImportError.
WebHelpers has a lot of undeclared dependencies, but that's consistent with its goal of being a grab-bag of utilities, some of which have diverse dependencies. You don't want to force all those myriad dependencies on everybody because that would make them avoid WebHelpers.
But Pylons is different because it claims to install a full stack, or at least what we define as a full stack. (Sessions yes, database no.) The dependencies were chosen to be small and pure Python, so that they wouldn't get in the way if you didn't use, e.g. FormEncode. Having undeclared dependencies in Pylons may surprise users or denegrade Pylons' reputation.
The excess dependencies could cause problems in low-capacity embedded systems, but the only place it has really mattered so far is App Engine, which (formerly) had severe file restrictions. But on App Engine, Pylons is installed via a manual upload rather than pip, which gives the opportunity to trim unused directories.
> On Wed, May 26, 2010 at 11:05 AM, Mike Orr <sluggos...@gmail.com> wrote: > > As for Pylons' dependencies (this is off the top of my head and may > > not be 100% accurate):
> > - Beaker: optional (activated in middleware.py) > > - decorator: optional, required for ``pylons.decorator`` utilities > > - FormEncode: optional > > - Nose: optional, required for tests > > - Paste: required > > - PasteDeploy: required, Pylons uses some utilities internally (asbool) > > - PasteScript: required, for "paster create" etc. > > - Routes: required. (Strictly speaking, RoutesMiddleware or a > > compatible alternative is required) > > - simplejson: optional, required for ``pylons.decorator`` utilities. > > (Included in Python 2.6.) > > - Tempita: required by Paste > > - WebError: required? (May be deactivated in middleware.py?) > > - WebHelpers: optional > > - WebOb: required > > - WebTest: required? Required for tests.
> Moving all the optional dependencies to the application would cause > Pylons to have some undeclared dependencies. For instance, > ``pylons.decorator.*`` is not required for Pylons to run. But if > somebody tries to use some of the utilities in it, they'll get an > ImportError.
Moving only the dependencies that are never imported in the Pylons source makes sense to me, and perhaps some of the existing dependencies can be (re)moved too. Another option might be to make use of the `extras_require` setuptools functionality, but that can be hard for new users to grok also.
> Sorry to be contrary, but I think this statement is somewhat > incorrect. A typical Pylons-based projects--created via `paster > create`--makes use of certain packages/libraries (by default), but > Pylons itself doesn't necessarily depend on those packages--*your
My scenario looks as follow: I've tried to move some service based on Pylons 0.9.7 (created using paster in 2009) to the new server a few months ago. I've installed fresh copy of Python and new Pylons instance from the scratch (using easy_install -U "Pylons==0.9.7"). After copy of application on destination environment a lot of errors were thrown related to Routes (used by WebHelpers). AFAIK comparing both instances I've noticed that two components were changed: WebHelpers and Routes. I didn't remember revision number, maybe it was beta? After back to the previous version of these components (0.6.4 and 1.10.3 respectively) everything is ok.
> that the dependency should be *removed* from Pylons itself (i.e., from
I agree with you. But according to information from requires.txt file these components are required: Routes>=1.10.3 WebHelpers>=0.6.4
Maybe Pylons should be provided as a standalone package with all required libraries included (bateries included LOL :) ) with proper versions? Every change in external library will cause update Pylons version postfix or something like that?
