Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pyNCS headless #4

Open
eneftci opened this issue Aug 23, 2012 · 4 comments
Open

pyNCS headless #4

eneftci opened this issue Aug 23, 2012 · 4 comments
Assignees

Comments

@eneftci
Copy link
Collaborator

eneftci commented Aug 23, 2012

I noticed that pyNCS does not load if no display is available. This is annoying if one wants to run through ssh in combination with nohup (I use this for starting a long experiment through ssh and leave at night). This can also be a problem for Mac users connecting to a server through ssh and that have no local X server.

The cause is traitsui.api in ConfAPI.py . The parameter object inherits from hastraits. There seems to be no easy way to cut its dependency to display. Enthought is certainly a nice tool in some cases, but documentation is awful for a package of its size and importance. So I am wondering whether we should get rid of any enthought calls in the core part of pyNCS (i.e. whatever is imported in init).

A workaround for the display problem is to use a virtual frame buffer:
xvfb-run --server-args="-screen 0 1024x768x24" python my_pyncs_script.py

@ghost ghost assigned sheiksadique Aug 23, 2012
@sheiksadique
Copy link
Collaborator

Yes I noticed that too.. Here is something i was considering doing

  1. Removing enthouht dependency entirely. That would be a pity because it would have been awesome for developing GUIs for demos.

  2. developing a fake enthought/chaco package so that those will be imported when the actual cannot be imported due to any reason at all.

  3. May be we should consider developing a sub package pyNCS.ui which will support GUI stuff and will ofcourse only work when possible. I dont have a clue at this moment how this will work. This would be in the direction you were suggesting.

Which do you prefer ? And how urgent is this issue ? Option 1 would be the quickest and 3 the slowest.

@eneftci
Copy link
Collaborator Author

eneftci commented Aug 23, 2012

Actually 3) is pretty good.

For example, you could have Parameter inherit from a HasTraitsAble (virtual) class that would have the functions necessary to cast it into a HasTraits. It is not urgent since there is a work around for this problem using the virtual framebuffer (xvfb).

@fabioedoardoluigialberto
Copy link
Collaborator

I also favour the 3rd option. Maybe it is going to be easy to implement with the guiqwt thing.

@sheiksadique
Copy link
Collaborator

New branch "headless" added.
Unit test runs without errors.
Can you guys beta test ? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants