[Grok-dev] Grok-dev Digest, Vol 70, Issue 7

[Leonardo Rochael Almeida]

One alternative I've used in the past to get PyDev to see all packages
in my project was to use collective.recipe.omelette[1] and add it's
directory only to the PyDev python path.

[1] http://pypi.python.org/pypi/collective.recipe.omelette

This works whether your eggs are shared (~/.buildout) or not.

Cheers,

Leo

On Tue, Jul 17, 2012 at 6:24 PM, Paul Sephton <prsephton at gmail.com> wrote:
> Hi, Uli
>
>
> On 17/07/2012 12:16, Uli Fouquet wrote:
>>
>> Hi Paul,
>>
>> On Tue, 17 Jul 2012 07:26:44 +0200 Paul Sephton wrote:
>>>
>>> On 16/07/2012 14:00, grok-dev-request at zope.org wrote:
>>>>
>>>> If installing a virtualenv is still recommended (and from my point of
>>>> view it is), we could make it the default (turning ``--virtualenv`` into
>>>> ``--no-virtualenv``).
>>>>
>>>> Beside this we might want an additional ``--download-base`` option to
>>>> allow download from other locations than PyPI.
>>>>
>>>> What would be the cons/side-effects?
>>>>
>>> I was under the impression that virtualenv was no longer required?
>>
>> Under special circumstances, I think, you still want virtualenvs.
>> Especially with some distributions that package eggs in a way not
>> compatible with setuptools. That can change from release to release (as
>> we now have seen with Feodora). As Sylvain said: in 90% of bootstrap
>> problems virtualenv seems to help.
>
> That's cool; I think it's a pity that those distros clash with setuptools,
> and it's understandable that creating an independent installation is
> preferable to hacking one's way through the version difference problems.  It
> will always be a problem where some python apps insist on newer egg versions
> than other python apps.
>
> The way system libraries handle the version difference problems is
> interesting by comparison.  By incrementing major library version only when
> the API interface changes, and incrementing the minor version whenever
> anything else changes, and naming the module to include major & minor
> numbers, it is possible to maintain binary compatibility after linking and
> yet allow for incremental library upgrades.  Effectively, older libraries
> may live alongside newer libraries ad-infinitum.  Python, on the other hand,
> expects libraries to have potential incompatibility only between interpreter
> versions, and actual library names remain the same between updates
> regardless of incompatible changes.  I'm sure there is something one could
> do, thinking about it.
>
>>> An immediate problem I could think of, is integration of the dev
>>> environment with tools like Eclipse (esp. for code
>>> completion/debugging).  As it stands, the eggs go in the ~/.buildout
>>> directory.  This would be different for virtualenv?  How would one tell
>>> Eclipse to share the same virtual environment?  I have never used
>>> virtualenv, so it's a bit intimidating :-)
>>>
>>> Speaking of this, integration with Eclipse/pydev/Aptana  is still not
>>> easy, even with the existence of recipes to help out on that front.
>>> There are just so many packages to add to the pythonpath.  If I could
>>> add an item to the wishlist...
>>
>> Of course you can :-) Just out of curiosity (as I never used Eclipse
>> with Python myself): what packages/recipes are required?
>
> Eclipse & Python rocks!  You absolutely need to try it to see if it suits
> you.
>
> The Eclipse package to install is pydev (part of Aptana Studio-
> http://www.aptana.com/).  Aptana can be installed as a standalone, or as
> part of Eclipse.  It also includes a remote debugger (pydevd) which is
> hugely useful when developing for Grok.  Somebody put together
> pb.recipes.pydev, which creates a new pydev project that contains all the
> Zope modules in the projects pythonpath.  I don't use that though, and
> instead add the modules I use manually- it's quite workable to do that,
> although it's a bit clumsy.
>
> To add pydev to Eclipse (3.4+), go "Help->Install New Software", then type
> in "http://pydev.org/updates" in the "Work with" box and click "Add".  To
> use the remote debugger, ensure that the directory containing the
> "pydevd.py" is in your pythonpath, and add "import pydevd;
> pydevd.settrace()" to your code at your intended breakpoint.
>
> pydev gives you syntax highlighting/checking, introspection, command
> completion, and a great debugger.  It also fully integrates DJango- which
> might be useful for someone else out there.  I don't use it myself.
>
> Just by the way, what are your thoughts on web2py as opposed to Grok?
>
> Regards,
> Paul
>
>
> --
> We will have solar energy as soon as the utility companies solve one
> technical problem -- how to run a sunbeam through a meter.
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> https://mail.zope.org/mailman/listinfo/grok-dev
>