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

venv activate script problems in POSIX #23

Open
juzhang opened this issue Oct 14, 2016 · 3 comments
Open

venv activate script problems in POSIX #23

juzhang opened this issue Oct 14, 2016 · 3 comments

Comments

@juzhang
Copy link

juzhang commented Oct 14, 2016

OS: Ubuntu 16.04
Version: 0.13.0 Delta

On opening a workflow with uninstalled plugins, when pluginmanager.installPackage is called (line 222):
activate_script = getActivateScript(self._virtualenv_dir)
returns None, causing

File "/usr/lib/python2.7/subprocess.py", line 711, in init
errread, errwrite)
File "/usr/lib/python2.7/subprocess.py", line 1343, in _execute_child
raise child_exception
AttributeError: 'NoneType' object has no attribute 'rfind'

In checks.getActivateScript, I think the correct venv_path
~/.config/MusculoSkeletal/MAPClient/venv/bin/activate
is passed but (line 176)
activate_script = which(os.path.join(venv_path, int_directory, 'activate' + suffix))
returns None because in utils.which, _access_check (line 66) returns False due to
os.access(fn, mode)
evaluating to False for mode=1.

~/.config/MusculoSkeletal/MAPClient/venv/bin/activate did not have execute permissions. When execute permission is manually given, getActivateScript(self._virtualenv_dir) returns the script path. However, then in pluginmanager line 223, the Popen call fails with

OSError: [Errno 8] Exec format error

Adding #!/bin/bash to the top of the activate script gets rid of this error but it doesn't seem the Popen call executes properly because immediately I get

mapclient.view.workflow.workflowwidget - ERROR - Invalid Workflow. The given Workflow configuration file was not loaded. You may need to restart the application to pick up newly installed Python modules

the uri for the missing plugin was correctly pass to installPackage.

@lennonab
Copy link

Hi,

I'd just like to confirm that I can replicate this issue on Ubuntu 16.04 with MAP client version 0.13.2.

The two steps you applied (making activate executable and adding #!/bin/bash) reproduce the same errors. I noticed in the activate script that it explicitly says to only execute it using source bin/activate from bash, so I wonder does the function used to call/execute it need to be modified in some way for the installPackage function to work?

Has anyone ever gotten this to work correctly on Ubuntu 16.04? In general, I've had a lot of trouble to get the mapclient installed on my system (although a 10 year break from doing anything significant with Python hasn't helped).

For reference, my installation includes a combination of system Python27 packages, with any dependencies I couldn't find installed via pip (which put everything in ~/.local/bin ~/.local/lib/python2.7). The quoted install method in the documentation (on both a Windows 7:Anaconda install as well as my main Ubuntu system) required some additional tweaks in the form of manual installation of pmr2.wfctrl (via pip) for both and symbolically linking 2to3 /usr/bin to 2to3.py in my Linux install as Ubuntu seems to drop the .py extension. I installed some extra packages that seemed to be necessary for some plugins (namely OpenSim 3.3 with python bindings and gias2) which went into ~/.local/lib/python2.7). I also installed Mayavi (via apt repository package mayavi2) as recommended by gias2. I think there were a couple of other issues that I also struggled with, such as where the default plugin directory is (putting git cloned plugins into the same folder as the installation plugin directory (/home/alex/.local/lib/python2.7/site-packages/mapclientplugins/) didn't seem to have any effect unless I point the plugin settings dialog at the specific directories that the plugins are cloned into.

My MAPClient.ini file looks like the following (in case there is anything in the general client settings that could also be causing problems):

[PMR]
active-pmr-website=http://teaching.physiomeproject.org
instances\1\pmr-website=http://teaching.physiomeproject.org
instances\1\user-public-token=
instances\1\user-secret-token=
instances\size=1

[MainWindow]
size=@SiZe(1192 693)
pos=@point(1910 14)

[Plugins]
load_defaults=true
donot_show_plugin_errors=false
virtualenv_setup_attempted=false
directories\size=0

[Ignored%20Plugins]
plugins\size=0

[Resource%20Filenames]
filenames\1\filenames=resources_rc
filenames\size=1

[Updater%20Settings]
settings\1\settings=resources - True
settings\2\settings=location - True
settings\3\settings=indentation - True
settings\4\settings=syntax - True
settings\size=4

[WorkflowManager]
previousLocation=

[Options]
checkBoxUseExternalGit=true
checkBoxShowStepNames=true
lineEditPySideUIC=/usr/bin/pyside-uic
lineEditGitExecutable=/usr/bin/git
lineEditPySideRCC=/usr/bin/pyside-rcc
checkBoxCheckToolsOnStartup=true
previous_write_step_location=
checkBoxDontCreateVirtualEnvironment=false
previous_icon_location=
lineEditVirtualEnvironmentPath=/home/alex/.config/MusculoSkeletal/MAPClient/venv_0.13.2

@lennonab
Copy link

Okay, just confirming my suspicion that it was to do with the Popen call in the installPackage function. Commenting out all the Popen related code and inserting the following shell command via os.system allows the packages to install.

shellcmd = 'bash -c '+'"source '+activate_script+'" && pip install '+uri
os.system(shellcmd)

Note that making the activate script is still required to be executable to have it found by which in getActivateScript.

None of the above is really a fix though as opening up the same workflow tries to reinstall all the already installed plugins. However, reverting to the old code once you have all required plugins installed seems to allow the workflow to be opened correctly again.

Unfortunately, running the workflow has resulted in some new errors related to XOpenGLRenderWindow upon execution of the workflow. This probably requires a new issue to be raised though (will have to be after the weekend at this stage).

@hsorby
Copy link
Contributor

hsorby commented Feb 20, 2017

Thanks I'll take a look at this.

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

No branches or pull requests

3 participants