cmake configure doesn't look for python-ply

[Patrick Farrell]

I checked out the trunk and built it just fine. However, when I try to import dolfin I get

/home/pef/src/dolfin/trunk/local/lib/python2.7/dist-packages/dolfin_utils/cppparser/CppHeaderParser.py in <module>()
     49 """
     50
---> 51 import ply.lex as lex
     52 import os
     53 import sys

ImportError: No module named ply.lex

It appears a dependency has been added on the python-ply package, but cmake hasn't been configured to demand it.

(Installing python-ply fixes the proximate problem.)

[Johannes Ring (johannr)]

Actually, I'm not sure we should add a check for PLY in the build system since it is only a runtime dependency. AFAIK, we do not have such a check for other runtime dependencies like FFC and UFL. Opinions?

[Johan Hake (johan-hake)]

We could make sure some of PyDOLFIN runtime dependencies are installed
by separately importing them. If they are not installed we can issue a
nicely formated message?

Johan

On 08/16/2012 08:21 AM, Johannes Ring wrote:
> Actually, I'm not sure we should add a check for PLY in the build system
> since it is only a runtime dependency. AFAIK, we do not have such a
> check for other runtime dependencies like FFC and UFL. Opinions?
>
> ** Changed in: dolfin
> Status: In Progress => Opinion
>
> ** Changed in: dolfin
> Importance: High => Medium
>

[Martin Sandve Alnæs (martinal)]

Good idea.

Martin
Den 16. aug. 2012 08:50 skrev "Johan Hake" <email address hidden>
følgende:

> We could make sure some of PyDOLFIN runtime dependencies are installed
> by separately importing them. If they are not installed we can issue a
> nicely formated message?
>
> Johan
>
> On 08/16/2012 08:21 AM, Johannes Ring wrote:
> > Actually, I'm not sure we should add a check for PLY in the build system
> > since it is only a runtime dependency. AFAIK, we do not have such a
> > check for other runtime dependencies like FFC and UFL. Opinions?
> >
> > ** Changed in: dolfin
> > Status: In Progress => Opinion
> >
> > ** Changed in: dolfin
> > Importance: High => Medium
> >
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1037311
>
> Title:
> cmake configure doesn't look for python-ply
>
> Status in DOLFIN:
> Opinion
>
> Bug description:
> I checked out the trunk and built it just fine. However, when I try to
> import dolfin I get
>
>
> /home/pef/src/dolfin/trunk/local/lib/python2.7/dist-packages/dolfin_utils/cppparser/CppHeaderParser.py
> in <module>()
> 49 """
> 50
> ---> 51 import ply.lex as lex
> 52 import os
> 53 import sys
>
> ImportError: No module named ply.lex
>
> It appears a dependency has been added on the python-ply package, but
> cmake hasn't been configured to demand it.
>
> (Installing python-ply fixes the proximate problem.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1037311/+subscriptions
>

[Garth Wells (garth-wells)]

On 16 August 2012 07:43, Johan Hake <email address hidden> wrote:
> We could make sure some of PyDOLFIN runtime dependencies are installed
> by separately importing them. If they are not installed we can issue a
> nicely formated message?
>

I would suggest just putting import inside a 'try' block, and print
an informative message if the import fails. I wouldn't bother
including it in the configure system.

Garth

> Johan
>
> On 08/16/2012 08:21 AM, Johannes Ring wrote:
>> Actually, I'm not sure we should add a check for PLY in the build system
>> since it is only a runtime dependency. AFAIK, we do not have such a
>> check for other runtime dependencies like FFC and UFL. Opinions?
>>
>> ** Changed in: dolfin
>> Status: In Progress => Opinion
>>
>> ** Changed in: dolfin
>> Importance: High => Medium
>>
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1037311
>
> Title:
> cmake configure doesn't look for python-ply
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1037311/+subscriptions

[Johannes Ring (johannr)]

I have improved the error message slightly now. Feel free to improve it further.

[Johan Hake (johan-hake)]

On 08/17/2012 10:24 AM, Johannes Ring wrote:
> I have improved the error message slightly now. Feel free to improve it
> further.

I did. I was working on a fix when you pushed.

We now handle all hard dependencies at one place. I thought of not
including ffc as it is an optional dependency, but included it anyway as
it is the default option for form compilers. ufc is also strictly
speaking checked at compile time, but included it anyway.

Johan

[Patrick Farrell (pefarrell)]

Personally, I think checking it only at runtime is a poor user experience. (But I think the general opinion disagrees with me.)

 It's surprising for a user to compile dolfin from source, get a success message, and then try to use it only to find that you still need to install more stuff. From a user's perspective, build dependencies and runtime dependencies are just dependencies. It doesn't particularly matter for the user experience how that dependency is used, it only matters that the user needs to install it before they can actually get on with whatever they really want to do. I had thought that I had done all the boring installation work, and then I found out that I actually hadn't.

It might be useful to have a warning at configure time that not all runtime dependencies are met (but still go ahead and build)?

[Garth Wells (garth-wells)]

On 17 August 2012 17:59, Patrick Farrell <email address hidden> wrote:
> Personally, I think checking it only at runtime is a poor user
> experience. (But I think the general opinion disagrees with me.)
>

It reasonable to check at runtime because:

1. The package is not always required. It's need for JIT compilation
only, so it would be best not to demand that it's installed. Most
users will you JIT, but they are many reasonable usage cases that
won't need JIT.

2. It's consistent with typical Python module handling.

3. The build system is already complicated (they always are), so the
more we can reasonably keep out of the build system the better.

Garth

> It's surprising for a user to compile dolfin from source, get a success
> message, and then try to use it only to find that you still need to
> install more stuff. From a user's perspective, build dependencies and
> runtime dependencies are just dependencies. It doesn't particularly
> matter for the user experience how that dependency is used, it only
> matters that the user needs to install it before they can actually get
> on with whatever they really want to do. I had thought that I had done
> all the boring installation work, and then I found out that I actually
> hadn't.
>
> It might be useful to have a warning at configure time that not all
> runtime dependencies are met (but still go ahead and build)?
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1037311
>
> Title:
> cmake configure doesn't look for python-ply
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/dolfin/+bug/1037311/+subscriptions