Help get Pylons 1.0 out the door!
Ben Bangert
Two documentation tickets:
http://pylonshq.com/project/pylonshq/query?status=assigned&status=new&status=reopened&group=status&milestone=1.0
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-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Graham Higgins
Hash: SHA1
On 19 May 2010, at 02:59, Ben Bangert wrote:
> 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:
> anything that warrants holding back a Pylons 1.0 release.
* #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)
http://bitbucket.org/gjhiggins/quickwiki
But I don't believe that it's fit for use just yet ...
http://bitbucket.org/gjhiggins/quickwiki/changeset/21520a734ca1
install_requires=[
- - "Pylons==1.0rc1dev-20100318",
+ "Pylons>=1.0rc1dev",
"SQLAlchemy>=0.5",
"docutils==0.6",
],
needs correcting to synchronise with the eventually-selected Pylons
release version string, whatever that be.
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".
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkvz07EACgkQOsmLt1NhivzOvQCdG+pL2mLaBhb3fXnmZ/2oTZG5
SD4AoKMlU/X+fDtYbGcJQ5hF3l5XNRk3iQCVAgUBS/PTsVnrWVZ7aXD1AQLfNAP/
X6ELqnaVXYvzcf/CDc+8HmBGmiayJ5hkP/9P4UJz+5kWPsi5TYr9VXJz2iA1knIH
NrcLdTBsE3fMuGyOkMLvr7j/Lx+rxgydBxQRSdZWgLeEut4SszXAi+nHiDyP9bdX
lfbOzC4PHHoeYjd4JFA5ioFHco/lTulWu8F3vGMXlJM=
=kxVN
-----END PGP SIGNATURE-----
Mike Burrows
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?
>
Ryan Arana
clemensherschel
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
> > 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:http://pylonshq.com/project/pylonshq/query?status=assigned&status=new.
> <mailto:pylons-discuss%2Bunsu...@googlegroups.com>.
> <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-...@googlegroups.com
> <mailto:pylons-discuss%2Bunsu...@googlegroups.com>.
artee
> stability, "SQLAlchemy>=0.5" oughtn't to be something like
> "SQLAlchemy>=0.5,<=0.6".
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.
cheers,
Artur
Mike Orr
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.
--
Mike Orr <slugg...@gmail.com>
Graham Higgins
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.
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkv8pfoACgkQOsmLt1Nhivx8gACdH9NuDVsqyiYjw98onZ2zcpcs
X8MAoKhskDCBp0t2AWn2C03HRYznu9NGiQCVAgUBS/yl+lnrWVZ7aXD1AQIZOAP+
JXURDaN/SYZrjw7gAEhVcqsTqMlUz6Fc/wlbidvSVxkOkxW/prEG6II+BlqlR/yP
xbns1k/pJK0gf+FK8WsCwAfxOGyj5BXDl+ajhbkPQ7uROEv+Mo6c7PE6j1abh1HP
RFNW9LbUqgFuL0/J9m6eUmR4TyHlaID7uHY+8J4KVFM=
=3k8J
-----END PGP SIGNATURE-----
Noah Gift
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.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
>
>
--
Thanks,
Noah
Graham Higgins
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).
- --
Cheers,
Graham
http://www.linkedin.com/in/ghiggins
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkv8qiEACgkQOsmLt1NhivzKngCfctexAOu3YMtP0a2TtdEPESGd
Vn4An28FHB6B32VWQ14uZ9xh5vCeHYkFiQCVAgUBS/yqIVnrWVZ7aXD1AQJiIAP/
Qm6XAv1gCXYkOgEYBUSpDq5KmWJU++riO0tks5gb/e73n9DURA45ghud2LVeEqG4
g3tfHmBXSQrpq3Bi42qFQ4cNRjh6Gc51GkpxuUuFfP0suytOignHuCS9cTijtyqA
zXalqQt9AfDHPlffyIVROaFAKcSzNFRAfwiUEcBEklk=
=RF2Z
-----END PGP SIGNATURE-----
Noah Gift
mentioned, I even liked the idea of having all the components
available in a bundle like an OS X application.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
>
>
--
Thanks,
Noah
artee
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 ;)
--
Thanks,
Artur
Graham Higgins
> * #688 (newline in signed cookie) seems still to be extant
JIC my PM to Ben is on a lonely tarpitted sojourn round the outer
planets:
#688 is solved by switching to the standard base64 alphabet:
base64.standard_b64decode
and
base64.standard_b64decode
(Also posted on trac)
Wyatt Baldwin
> > 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?
whit
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?
-w
> On Tue, May 25, 2010 at 9:57 PM, Graham Higgins <gjhiggins-Re5JQE...@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).
>>
>> - --
>> Cheers,
>>
>> Graham
>>
>> http://www.linkedin.com/in/ghiggins
>>
>>
>>
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iEYEARECAAYFAkv8qiEACgkQOsmLt1NhivzKngCfctexAOu3YMtP0a2TtdEPESGd
>> Vn4An28FHB6B32VWQ14uZ9xh5vCeHYkFiQCVAgUBS/yqIVnrWVZ7aXD1AQJiIAP/
>> Qm6XAv1gCXYkOgEYBUSpDq5KmWJU++riO0tks5gb/e73n9DURA45ghud2LVeEqG4
>> g3tfHmBXSQrpq3Bi42qFQ4cNRjh6Gc51GkpxuUuFfP0suytOignHuCS9cTijtyqA
>> zXalqQt9AfDHPlffyIVROaFAKcSzNFRAfwiUEcBEklk=
>> =RF2Z
>> -----END PGP SIGNATURE-----
>>
>> --
>> 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/Ez6Z...@public.gmane.org
>> To unsubscribe from this group, send email to
>> pylons-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6Z...@public.gmane.org
>> For more options, visit this group at
>> http://groups.google.com/group/pylons-discuss?hl=en.
>>
>>
>
>
>
--
>>>
Whit Morriss
CodeMonkey
wh...@surveymonkey.com
-- We're hiring pythonista: http://bit.ly/cT0ELi --
Wyatt Baldwin
>
> [...]
>
> 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.
Noah Gift
On Wed, May 26, 2010 at 8:52 AM, whit <wh...@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.
> To post to this group, send email to pylons-...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-discus...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.
>
>
--
Thanks,
Noah
Mike Orr
>> 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.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
<wyatt.le...@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).
>
> 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.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
> 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.
--
Mike Orr <slugg...@gmail.com>
Wyatt Baldwin
> 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.
artee
> 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
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?
--
Thanks,
Artur