Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Great! that fixed the issue On Fri, Aug 26, 2016 at 10:20 AM, Dannon Baker wrote: > Ok, so it should be gone, I guess. Check 'git status', maybe it's just > there as an untracked file (and if so, just rm it)? > > On Fri, Aug 26, 2016 at 12:55 PM, D K

[galaxy-dev] Introducing Conda as a new standard for Galaxy tool dependencies

Hi all, Galaxy 16.07 was just released: https://docs.galaxyproject.org/en/master/releases/16.07_announce.html and the IUC has some news to share with you. For a more readable version please see: https://docs.galaxyproject.org/en/master/admin/conda_faq.html Galaxy tools (also called

Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Ok, so it should be gone, I guess. Check 'git status', maybe it's just there as an untracked file (and if so, just rm it)? On Fri, Aug 26, 2016 at 12:55 PM, D K wrote: > Hi Dannon, > > There's your commit where you describe removing it. So why is it still > there if I

Re: [galaxy-dev] Workflow Compatibility

Hi Brad, So with multiple selection dropdown lists this is possible? Do you have an example of a tool that can do this? Would it be possible to see an example of the tools you are talking about? Thanks for the help! Katherine On Fri, Aug 26, 2016 at 12:05 PM, Langhorst, Brad

Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Can you check the git log for that controller, to see how it got added back to, or remained in, the codebase? On Fri, Aug 26, 2016, 12:40 PM D K wrote: > Hi Dannon, > > Yes, the > "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py" >

Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Hi Dannon, Yes, the "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py" does still exist. If it's relevant I did a: git commit -a -m 'changes made locally prior to upgrade to 16.07' git pull origin master I had to move the file

Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Can you check to see if that file (/remote/home/galaxyd/tmp/ galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py) does still exist? If it does not, it may be a leftover .pyc file (which you can delete safely). If you'd like to just clean out *all* the compiled python (which is also

Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

I have modified some files in my own local galaxy commit (I think only the sniffers in lib/galaxy/datatypes) On Fri, Aug 26, 2016 at 9:31 AM, Dannon Baker wrote: > Hey DK, > > The cloudlaunch controller was deprecated and should not be in 16.07. Is > this a custom

Re: [galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Hey DK, The cloudlaunch controller was deprecated and should not be in 16.07. Is this a custom modification you have? -Dannon On Fri, Aug 26, 2016 at 12:30 PM, D K wrote: > Hi Galaxy-devs, > > I just tried upgrading to 16.07 from 16.01 and get this error when >

[galaxy-dev] Upgrade to Galaxy 16.07, import dumps problem

Hi Galaxy-devs, I just tried upgrading to 16.07 from 16.01 and get this error when starting up: > Traceback (most recent call last): > File "./scripts/paster.py", line 26, in > serve.run() > File > "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py", > line 1061, in

Re: [galaxy-dev] Workflow Compatibility

Hi Katherine: I’d recommend not having users type in paths if at all possible (they will make frustrating mistakes). If there is a selection of these maybe consider turining them into dropdown lists. Either way, these would be no different than e.g. user specified downsampling amounts. or

Re: [galaxy-dev] Workflow Compatibility

Hi Brad, What if its multiple file paths that the user types in rather than actual files, which makes it so the tool can't be executed in batch mode, would it still be workflow compatible at that point? Thanks for pointing me to the Bowtie wrappers as an example. Katherine On Fri, Aug 26, 2016 at

Re: [galaxy-dev] Workflow Compatibility

On Fri, Aug 26, 2016 at 10:42 AM, Katherine Beaulieu < katherine.beaulieu...@gmail.com> wrote: > Hi Peter, > I think I did not explain myself well. I meant that if I have a tool that > takes multiple file paths and outputs multiple Galaxy datasets to the > history, would this tool be workflow

Re: [galaxy-dev] Workflow Compatibility

Hi Katherine, Are you asking about compatibility staying on the same Galaxy instance, or the harder problem of compatibility sharing workflows between Galaxy servers? Taking data from input Galaxy datasets should be fine, anything else may not be portable. Even the relatively simple case of

[galaxy-dev] Workflow Compatibility

Hi Everyone, Would anyone be able to tell me the conditions which would make a tool non-workflow compatible? I have a tool that imports files from a third party application and auto-detects the file format. There is also the option to upload multiple files at once so the tool always uploads at

[galaxy-dev] Loading GUI on galaxy

Hello, I want to know, whether it is possible to embed graphical user interface like that of WEKA VisualizePanel tool in galaxy ? I am able to do it on a local instance of galaxy. But when i am trying to access the server (in which galaxy is installed) this GUI is not able to load on remote

Re: [galaxy-dev] Putting it all together - toolshed tool + conda dependency

Hi Steve, Looks like you're running an older version of galaxy in the docker container, since newer galaxy will build the metadata environment in a separate environment called 'conda-metadata-env', and we have also changed the way that the handlers receive their Python environment (that's why