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

[D K]

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  wrote:
>
>> Hi Dannon,
>>
>> There's your commit where you describe removing it. So why is it still
>> there if I did a git pull (did I do this incorrectly?)?
>>
>> I did a "git log -- cloudlaunch.py" and got the following:
>>
>> commit 303597e48a8503aac09c33910aa5482a374f06a1
>> Author: Dannon Baker 
>> Date:   Wed Aug 12 14:17:44 2015 -0400
>>
>> Remove old cloudlaunch in favor of https://github.com/galaxyproje
>> ct/cloudlaunch, at launch.usegalaxy.org
>>
>> commit 6049a7446897baea74c33a5286b6c086c9da31a8
>> Author: Dannon Baker 
>> Date:   Tue Jul 21 14:03:22 2015 -0400
>>
>> Catch and return error message during key verification in cloudlaunch.
>>
>> commit 09719b884806fe1da24b2f7be0f159f1d3b06d04
>> Author: dannon 
>> Date:   Sat Mar 7 22:51:35 2015 -0500
>>
>> Cleanup in pbed_to_lped converter
>> .
>> .
>> .
>>
>>
>> On Fri, Aug 26, 2016 at 9:49 AM, Dannon Baker 
>> wrote:
>>
>>> 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"
 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 "lib/galaxy/datatypes/checkers.py" but
 otherwise didn't get any other errors


 On Fri, Aug 26, 2016 at 9:38 AM, Dannon Baker 
 wrote:

> Can you check to see if that file (/remote/home/galaxyd/tmp/gala
> xy2/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 safe), run something like ```find  -name 
> "*.pyc"
> -delete```.
>
> On Fri, Aug 26, 2016 at 12:35 PM, D K 
> wrote:
>
>> 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 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
 starting up:


> Traceback (most recent call last):
>   File "./scripts/paster.py", line 26, in 
> serve.run()
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/serve.py", line 1061, in run
> invoke(command, command_name, options, args[1:])
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/serve.py", line 1067, in invoke
> exit_code = runner.run(args)
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/serve.py", line 223, in run
> result = self.command()
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/serve.py", line 639, in command
> app = loadapp( app_spec, name=app_name, relative_to=base,
> global_conf=vars)
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/loadwsgi.py", line 292, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/loadwsgi.py", line 317, in loadobj
> return context.create()
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/loadwsgi.py", line 755, in create
> return self.object_type.invoke(self)
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/loadwsgi.py", line 274, in invoke
> filtered = context.next_context.create()
>   File "/remote/home/galaxyd/tmp/gala
> xy2/lib/galaxy/util/pastescript/loadwsgi.py", line 755, in create
> return self.object_type.invoke(self)
>   File "/remote/home/galaxyd/tmp/gala
> 

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

[Björn Grüning]

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 wrappers) traditionally use Tool Shed package
recipes to install their dependencies. At the tool’s installation time
the recipe is downloaded and executed in order to provide the underlying
software executables. Introduction of these Galaxy-specific recipes was
a necessary step at the time, however nowadays there are other more
mature and stable options to install software in a similar manner. The
Galaxy community has taken steps to improve the tool dependency system
in order to enable new features and expand its reach. This document aims
to describe these and answer the FAQ.

It is a pleasure to announce the adoption of a new standard for tool
dependencies in Galaxy which has been integrated over the last six
months: Conda packages!
Not only do Conda packages make tool dependencies more reliable and
stable, they are also easier to test and faster to develop than the
traditional Tool Shed package recipes .

Conda is a package manager like apt-get, yum, pip, brew or guix. We
don’t want to argue about the relative merits of various package
managers here, in fact Galaxy supports multiple package managers and we
welcome community contributions (such as implementing a Guix package
manager or enhancing the existing brew support to bring it on par with
Conda).

As a community, we have decided that Conda is the one that best fulfills
our needs. The following are some of the crucial Conda features that led
to this decision:

* Installation of packages does not require root privileges
(Installation at any location  the Galaxy user has write access to)
* Multiple versions of software can be installed in parallel
* HPC-ready
* Faster and more robust package installations through pre-compiled
packages (no build environment complications)
* Independent of programming language (R, Perl, Python, Julia, Java,
pre-compiled binaries, and more)
* Easy to write recipes (1 YAML description file + 1 Bash install script)
* An active, large and growing community (with more and more software
authors managing their own recipes)
* Extensive documentation: Conda documentation
(http://conda.pydata.org/docs/building/build.html) and Conda quick-start
(http://conda.pydata.org/docs/get-started.html)

Below we answer some common questions (collected by Lance Parsons):

1. How do I enable Conda dependency resolution for existing Galaxy
installations?
---

Most Galaxy administrators have not set up a dependency resolvers
configuration file (dependency_resolvers_conf.xml) which means they are
using Galaxy’s default (dependency_resolvers_conf.xml.sample). Galaxy
has enabled Conda dependency resolution by default since release 16.04
(if Conda was installed already), so many existing installations can use
Conda dependencies. Having Conda enabled in
dependency_resolvers_conf.xml means that Galaxy will look for
dependencies using the Conda system when it attempts to run tools. If
conda_auto_install is True, and a dependency is not found, Galaxy will
attempt to install it using the configured Conda channels. A graphical
user interface that allows administrators install Conda packages
directly from Galaxy when tools are installed from the Tool Shed is
available in the 16.07 release of Galaxy.


2. How do Conda dependencies work? Where do things get installed?
-
In contrast to the old dependency system, which was used exclusively by
Galaxy, Conda is a pre-existing, independent project. With Conda it is
possible for an admin to install packages without touching Galaxy at all
– managing your dependencies independently from Galaxy. Galaxy can
handle these dependencies for you, but admins are not required to use
Galaxy for dependency management.

There are a few new config options in the galaxy.ini file, but by
default Galaxy will install Conda (the package manager) and the required
packages in the /_conda/ directory. In this
directory, Galaxy will create an envs folder with all of the
environments managed by Galaxy. Every environment contains a lib, bin,
share, and include subdirectory, depending on the tool, and is
sufficient to get a Galaxy tool up and running. Galaxy simply sources
this folder via Conda and makes everything available before the tool is
executed on your cluster.

To summarize, there are four ways to manage Conda dependencies for use
with Galaxy. For all of these options, Conda dependency management must
be configured in the dependency_resolvers_conf.xml and the galaxy.ini file.

a) Manual Install - Conda dependencies may be installed by
administrators from the command line. Conda (and thus the conda
environments) should be 

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

[Dannon Baker]

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 did a git pull (did I do this incorrectly?)?
>
> I did a "git log -- cloudlaunch.py" and got the following:
>
> commit 303597e48a8503aac09c33910aa5482a374f06a1
> Author: Dannon Baker 
> Date:   Wed Aug 12 14:17:44 2015 -0400
>
> Remove old cloudlaunch in favor of https://github.com/
> galaxyproject/cloudlaunch, at launch.usegalaxy.org
>
> commit 6049a7446897baea74c33a5286b6c086c9da31a8
> Author: Dannon Baker 
> Date:   Tue Jul 21 14:03:22 2015 -0400
>
> Catch and return error message during key verification in cloudlaunch.
>
> commit 09719b884806fe1da24b2f7be0f159f1d3b06d04
> Author: dannon 
> Date:   Sat Mar 7 22:51:35 2015 -0500
>
> Cleanup in pbed_to_lped converter
> .
> .
> .
>
>
> On Fri, Aug 26, 2016 at 9:49 AM, Dannon Baker 
> wrote:
>
>> 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"
>>> 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 "lib/galaxy/datatypes/checkers.py" but otherwise
>>> didn't get any other errors
>>>
>>>
>>> On Fri, Aug 26, 2016 at 9:38 AM, Dannon Baker 
>>> wrote:
>>>
 Can you check to see if that file (/remote/home/galaxyd/tmp/gala
 xy2/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 safe), run something like ```find  -name "*.pyc"
 -delete```.

 On Fri, Aug 26, 2016 at 12:35 PM, D K  wrote:

> 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 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
>>> 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 run
 invoke(command, command_name, options, args[1:])
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
 line 1067, in invoke
 exit_code = runner.run(args)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
 line 223, in run
 result = self.command()
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
 line 639, in command
 app = loadapp( app_spec, name=app_name, relative_to=base,
 global_conf=vars)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 292, in loadapp
 return loadobj(APP, uri, name=name, **kw)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 317, in loadobj
 return context.create()
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 755, in create
 return self.object_type.invoke(self)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 274, in invoke
 filtered = context.next_context.create()
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 755, in create
 return self.object_type.invoke(self)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 191, in invoke
 return fix_call(context.object, context.global_conf,
 **context.local_conf)
   File 
 

Re: [galaxy-dev] Workflow Compatibility

[Katherine Beaulieu]

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  wrote:

> 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 library names, etc.
> I have tools that accept many of these.
>
>
> Brad
>
> —
> Brad Langhorst, Ph.D.
> Development Scientist
> New England Biolabs
>
>
>
>
> On Aug 26, 2016, at 10:57 AM, Katherine Beaulieu <
> katherine.beaulieu...@gmail.com> wrote:
>
> 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.
>
>
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

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

[Dannon Baker]

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"
> 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 "lib/galaxy/datatypes/checkers.py" but otherwise
> didn't get any other errors
>
>
> On Fri, Aug 26, 2016 at 9:38 AM, Dannon Baker 
> wrote:
>
>> 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 safe), run something like ```find  -name "*.pyc"
>> -delete```.
>>
>> On Fri, Aug 26, 2016 at 12:35 PM, D K  wrote:
>>
>>> 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 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
> 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 run
>> invoke(command, command_name, options, args[1:])
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>> line 1067, in invoke
>> exit_code = runner.run(args)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>> line 223, in run
>> result = self.command()
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>> line 639, in command
>> app = loadapp( app_spec, name=app_name, relative_to=base,
>> global_conf=vars)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 292, in loadapp
>> return loadobj(APP, uri, name=name, **kw)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 317, in loadobj
>> return context.create()
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 755, in create
>> return self.object_type.invoke(self)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 274, in invoke
>> filtered = context.next_context.create()
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 755, in create
>> return self.object_type.invoke(self)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 191, in invoke
>> return fix_call(context.object, context.global_conf,
>> **context.local_conf)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 94, in fix_call
>> val = callable(*args, **kw)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
>> line 39, in app_factory
>> return paste_app_factory( global_conf, **kwargs )
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
>> line 76, in paste_app_factory
>> webapp.add_ui_controllers( 'galaxy.webapps.galaxy.controllers',
>> app )
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/web/framework/webapp.py", 
>> line
>> 115, in add_ui_controllers
>> module = import_module( module_name )
>>   File
>> "/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py", line 
>> 37,
>> in import_module
>> __import__(name)
>>   File
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py",
>> line 16, in 
>> from galaxy.util.json import dumps
>> ImportError: cannot import name dumps
>
>
> Any suggestions?
>
> Thanks!
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy 

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

[D K]

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 "lib/galaxy/datatypes/checkers.py" but otherwise
didn't get any other errors


On Fri, Aug 26, 2016 at 9:38 AM, Dannon Baker 
wrote:

> Can you check to see if that file (/remote/home/galaxyd/tmp/gala
> xy2/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 safe), run something like ```find  -name "*.pyc"
> -delete```.
>
> On Fri, Aug 26, 2016 at 12:35 PM, D K  wrote:
>
>> 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 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
 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 run
> invoke(command, command_name, options, args[1:])
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
> line 1067, in invoke
> exit_code = runner.run(args)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
> line 223, in run
> result = self.command()
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
> line 639, in command
> app = loadapp( app_spec, name=app_name, relative_to=base,
> global_conf=vars)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 292, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 317, in loadobj
> return context.create()
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 755, in create
> return self.object_type.invoke(self)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 274, in invoke
> filtered = context.next_context.create()
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 755, in create
> return self.object_type.invoke(self)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 191, in invoke
> return fix_call(context.object, context.global_conf,
> **context.local_conf)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 94, in fix_call
> val = callable(*args, **kw)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
> line 39, in app_factory
> return paste_app_factory( global_conf, **kwargs )
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
> line 76, in paste_app_factory
> webapp.add_ui_controllers( 'galaxy.webapps.galaxy.controllers',
> app )
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/web/framework/webapp.py",
> line 115, in add_ui_controllers
> module = import_module( module_name )
>   File "/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py",
> line 37, in import_module
> __import__(name)
>   File 
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py",
> line 16, in 
> from galaxy.util.json import dumps
> ImportError: cannot import name dumps


 Any suggestions?

 Thanks!

 ___
 Please keep all replies on the list by using "reply all"
 in your mail client.  To manage your subscriptions to this
 and other Galaxy lists, please use the interface at:
   https://lists.galaxyproject.org/

 To search Galaxy mailing lists use the unified search at:
   http://galaxyproject.org/search/mailinglists/

>>>
>>>
>>
>
___
Please keep all replies on the list by using "reply 

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

[Dannon Baker]

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 safe), run something like ```find  -name "*.pyc"
-delete```.

On Fri, Aug 26, 2016 at 12:35 PM, D K  wrote:

> 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 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
>>> 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 run
 invoke(command, command_name, options, args[1:])
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
 line 1067, in invoke
 exit_code = runner.run(args)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
 line 223, in run
 result = self.command()
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
 line 639, in command
 app = loadapp( app_spec, name=app_name, relative_to=base,
 global_conf=vars)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 292, in loadapp
 return loadobj(APP, uri, name=name, **kw)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 317, in loadobj
 return context.create()
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 755, in create
 return self.object_type.invoke(self)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 274, in invoke
 filtered = context.next_context.create()
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 755, in create
 return self.object_type.invoke(self)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 191, in invoke
 return fix_call(context.object, context.global_conf,
 **context.local_conf)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
 line 94, in fix_call
 val = callable(*args, **kw)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
 line 39, in app_factory
 return paste_app_factory( global_conf, **kwargs )
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
 line 76, in paste_app_factory
 webapp.add_ui_controllers( 'galaxy.webapps.galaxy.controllers',
 app )
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/web/framework/webapp.py",
 line 115, in add_ui_controllers
 module = import_module( module_name )
   File "/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py",
 line 37, in import_module
 __import__(name)
   File 
 "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py",
 line 16, in 
 from galaxy.util.json import dumps
 ImportError: cannot import name dumps
>>>
>>>
>>> Any suggestions?
>>>
>>> Thanks!
>>>
>>> ___
>>> Please keep all replies on the list by using "reply all"
>>> in your mail client.  To manage your subscriptions to this
>>> and other Galaxy lists, please use the interface at:
>>>   https://lists.galaxyproject.org/
>>>
>>> To search Galaxy mailing lists use the unified search at:
>>>   http://galaxyproject.org/search/mailinglists/
>>>
>>
>>
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

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

[D K]

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 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
>> 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 run
>>> invoke(command, command_name, options, args[1:])
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>>> line 1067, in invoke
>>> exit_code = runner.run(args)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>>> line 223, in run
>>> result = self.command()
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>>> line 639, in command
>>> app = loadapp( app_spec, name=app_name, relative_to=base,
>>> global_conf=vars)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 292, in loadapp
>>> return loadobj(APP, uri, name=name, **kw)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 317, in loadobj
>>> return context.create()
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 755, in create
>>> return self.object_type.invoke(self)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 274, in invoke
>>> filtered = context.next_context.create()
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 755, in create
>>> return self.object_type.invoke(self)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 191, in invoke
>>> return fix_call(context.object, context.global_conf,
>>> **context.local_conf)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>>> line 94, in fix_call
>>> val = callable(*args, **kw)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
>>> line 39, in app_factory
>>> return paste_app_factory( global_conf, **kwargs )
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
>>> line 76, in paste_app_factory
>>> webapp.add_ui_controllers( 'galaxy.webapps.galaxy.controllers', app
>>> )
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/web/framework/webapp.py",
>>> line 115, in add_ui_controllers
>>> module = import_module( module_name )
>>>   File "/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py",
>>> line 37, in import_module
>>> __import__(name)
>>>   File 
>>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py",
>>> line 16, in 
>>> from galaxy.util.json import dumps
>>> ImportError: cannot import name dumps
>>
>>
>> Any suggestions?
>>
>> Thanks!
>>
>> ___
>> Please keep all replies on the list by using "reply all"
>> in your mail client.  To manage your subscriptions to this
>> and other Galaxy lists, please use the interface at:
>>   https://lists.galaxyproject.org/
>>
>> To search Galaxy mailing lists use the unified search at:
>>   http://galaxyproject.org/search/mailinglists/
>>
>
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

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

[Dannon Baker]

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
> 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 run
>> invoke(command, command_name, options, args[1:])
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>> line 1067, in invoke
>> exit_code = runner.run(args)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>> line 223, in run
>> result = self.command()
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
>> line 639, in command
>> app = loadapp( app_spec, name=app_name, relative_to=base,
>> global_conf=vars)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 292, in loadapp
>> return loadobj(APP, uri, name=name, **kw)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 317, in loadobj
>> return context.create()
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 755, in create
>> return self.object_type.invoke(self)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 274, in invoke
>> filtered = context.next_context.create()
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 755, in create
>> return self.object_type.invoke(self)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 191, in invoke
>> return fix_call(context.object, context.global_conf,
>> **context.local_conf)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
>> line 94, in fix_call
>> val = callable(*args, **kw)
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
>> line 39, in app_factory
>> return paste_app_factory( global_conf, **kwargs )
>>   File 
>> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
>> line 76, in paste_app_factory
>> webapp.add_ui_controllers( 'galaxy.webapps.galaxy.controllers', app )
>>   File "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/web/framework/webapp.py",
>> line 115, in add_ui_controllers
>> module = import_module( module_name )
>>   File "/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py",
>> line 37, in import_module
>> __import__(name)
>>   File "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/
>> galaxy/controllers/cloudlaunch.py", line 16, in 
>> from galaxy.util.json import dumps
>> ImportError: cannot import name dumps
>
>
> Any suggestions?
>
> Thanks!
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

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

[D K]

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 run
> invoke(command, command_name, options, args[1:])
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
> line 1067, in invoke
> exit_code = runner.run(args)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
> line 223, in run
> result = self.command()
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/serve.py",
> line 639, in command
> app = loadapp( app_spec, name=app_name, relative_to=base,
> global_conf=vars)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 292, in loadapp
> return loadobj(APP, uri, name=name, **kw)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 317, in loadobj
> return context.create()
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 755, in create
> return self.object_type.invoke(self)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 274, in invoke
> filtered = context.next_context.create()
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 755, in create
> return self.object_type.invoke(self)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 191, in invoke
> return fix_call(context.object, context.global_conf,
> **context.local_conf)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/util/pastescript/loadwsgi.py",
> line 94, in fix_call
> val = callable(*args, **kw)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
> line 39, in app_factory
> return paste_app_factory( global_conf, **kwargs )
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/buildapp.py",
> line 76, in paste_app_factory
> webapp.add_ui_controllers( 'galaxy.webapps.galaxy.controllers', app )
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/web/framework/webapp.py", line
> 115, in add_ui_controllers
> module = import_module( module_name )
>   File "/opt/rh/python27/root/usr/lib64/python2.7/importlib/__init__.py",
> line 37, in import_module
> __import__(name)
>   File
> "/remote/home/galaxyd/tmp/galaxy2/lib/galaxy/webapps/galaxy/controllers/cloudlaunch.py",
> line 16, in 
> from galaxy.util.json import dumps
> ImportError: cannot import name dumps


Any suggestions?

Thanks!
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Workflow Compatibility

[Langhorst, Brad]

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 library names, etc.
I have tools that accept many of these.


Brad

—
Brad Langhorst, Ph.D.
Development Scientist
New England Biolabs




On Aug 26, 2016, at 10:57 AM, Katherine Beaulieu 
> wrote:

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.


___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Workflow Compatibility

[Katherine Beaulieu]

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 10:45 AM, Langhorst, Brad  wrote:

> HI Katherine:
>
> Multi-input/output should work fine…
>
> You could have a look at the bowtie wrappers for an example.
>
> It takes up to 2 fastq files and a reference. I can output a few files
> (unmapped, mapped, etc)
>
>
> Brad
> —
> Brad Langhorst, Ph.D.
> Development Scientist
> New England Biolabs
>
>
>
>
> On Aug 26, 2016, at 10:42 AM, Katherine Beaulieu <
> katherine.beaulieu...@gmail.com> wrote:
>
>
>
> 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 compatible, meaning capable of being a
>> part of any workflow? From the behaviour I am getting now I am assuming it
>> isn't but I just wanted to confirm that this isn't supported functionality.
>>
>> On Fri, Aug 26, 2016 at 10:34 AM, Peter Cock 
>> wrote:
>>
>>> 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 using
>>> datafiles referenced via an example.loc file (e.g. BLAST databases)
>>> would require the entries in the example.loc file be synchronised
>>> between Galaxy instances, and the associated data files too.
>>>
>>> Peter
>>>
>>>
>>> On Fri, Aug 26, 2016 at 1:27 PM, Katherine Beaulieu
>>>  wrote:
>>> > 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 least two
>>> files.
>>> > From what I have described can anyone see why this tool would not be
>>> able to
>>> > send one of its files to the next tool in the chain, ex. a text
>>> manipulation
>>> > tool?
>>> > Thanks,
>>> > Katherine
>>> >
>>> > ___
>>> > Please keep all replies on the list by using "reply all"
>>> > in your mail client.  To manage your subscriptions to this
>>> > and other Galaxy lists, please use the interface at:
>>> >   https://lists.galaxyproject.org/
>>> >
>>> > To search Galaxy mailing lists use the unified search at:
>>> >   http://galaxyproject.org/search/mailinglists/
>>>
>>
>>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>  https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>  http://galaxyproject.org/search/mailinglists/
>
>
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Workflow Compatibility

[Katherine Beaulieu]

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 compatible, meaning capable of being a
> part of any workflow? From the behaviour I am getting now I am assuming it
> isn't but I just wanted to confirm that this isn't supported functionality.
>
> On Fri, Aug 26, 2016 at 10:34 AM, Peter Cock 
> wrote:
>
>> 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 using
>> datafiles referenced via an example.loc file (e.g. BLAST databases)
>> would require the entries in the example.loc file be synchronised
>> between Galaxy instances, and the associated data files too.
>>
>> Peter
>>
>>
>> On Fri, Aug 26, 2016 at 1:27 PM, Katherine Beaulieu
>>  wrote:
>> > 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 least two
>> files.
>> > From what I have described can anyone see why this tool would not be
>> able to
>> > send one of its files to the next tool in the chain, ex. a text
>> manipulation
>> > tool?
>> > Thanks,
>> > Katherine
>> >
>> > ___
>> > Please keep all replies on the list by using "reply all"
>> > in your mail client.  To manage your subscriptions to this
>> > and other Galaxy lists, please use the interface at:
>> >   https://lists.galaxyproject.org/
>> >
>> > To search Galaxy mailing lists use the unified search at:
>> >   http://galaxyproject.org/search/mailinglists/
>>
>
>
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

Re: [galaxy-dev] Workflow Compatibility

[Peter Cock]

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 using
datafiles referenced via an example.loc file (e.g. BLAST databases)
would require the entries in the example.loc file be synchronised
between Galaxy instances, and the associated data files too.

Peter


On Fri, Aug 26, 2016 at 1:27 PM, Katherine Beaulieu
 wrote:
> 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 least two files.
> From what I have described can anyone see why this tool would not be able to
> send one of its files to the next tool in the chain, ex. a text manipulation
> tool?
> Thanks,
> Katherine
>
> ___
> Please keep all replies on the list by using "reply all"
> in your mail client.  To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
>   https://lists.galaxyproject.org/
>
> To search Galaxy mailing lists use the unified search at:
>   http://galaxyproject.org/search/mailinglists/
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

[galaxy-dev] Workflow Compatibility

[Katherine Beaulieu]

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 least
two files. From what I have described can anyone see why this tool would
not be able to send one of its files to the next tool in the chain, ex. a
text manipulation tool?
Thanks,
Katherine
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

[galaxy-dev] Loading GUI on galaxy

[Lijo John]

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 desktop.


John
___
Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
  https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at:
  http://galaxyproject.org/search/mailinglists/

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

[Marius van den Beek]

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 sqlalachemy couldn't be found).

Can you try updating the container or building from the dev branch? I think
the necessary changes for conda should be in the dev branch, which you can
pull with docker pull quay.io/bgruening/galaxy:dev.

Best,

Marius

On Aug 26, 2016 6:49 AM, "Steve Cassidy"  wrote:

> Ok, probing further trying to understand this. It looks like the job
> runner is trying to call set_meta() from galaxy_ext/metadata/set_metadata.py.
> In there there’s a line that tries to set up the PATH:
>
> # insert *this* galaxy before all others on sys.path
> sys.path.insert( 1, os.path.abspath( os.path.join( os.path.dirname(
> __file__ ), os.pardir, os.pardir ) ) )
>
> In my case the result is:
>
> ['/export/galaxy-central/database/job_working_directory/000/3’,
> '/galaxy-central/lib’,
> '/galaxy-central/lib’,
>  '/export/galaxy-central/database/job_working_directory/000/
> 3/conda-env/lib/python27.zip’,
>  '/export/galaxy-central/database/job_working_directory/000/
> 3/conda-env/lib/python2.7’,
>  '/export/galaxy-central/database/job_working_directory/000/
> 3/conda-env/lib/python2.7/plat-linux2’,
>  '/export/galaxy-central/database/job_working_directory/000/
> 3/conda-env/lib/python2.7/lib-tk’,
> '/export/galaxy-central/database/job_working_directory/000/3
> /conda-env/lib/python2.7/lib-old’,
>  '/export/galaxy-central/database/job_working_directory/000/
> 3/conda-env/lib/python2.7/lib-dynload’,
> '/export/galaxy-central/database/job_working_directory/000/3
> /conda-env/lib/python2.7/site-packages’,
> '/export/galaxy-central/database/job_working_directory/000/3
> /conda-env/lib/python2.7/site-packages/setuptools-25.1.6-py2.7.egg’
> ]
>
> Looking for sqlalchemy, I find it installed at:
>
> /galaxy-central/.venv/lib/python2.7/site-packages/sqlalchemy
>
> so clearly that line of code is not doing what it should. I’m guessing
> that the Conda resolver is running the script within a conda env and the
> BETA magic hasn’t quite made it to the right place yet…
>
> BTW I was trying to understand the flags you mentioned but I can’t find
> GALAXY_CONFIG_ENABLE_BETA_TOOL_COMMAND_ISOLATION anywhere other than in
> sample Dockerfiles - is this some kind of magic incantation that creates a
> rift in space-time…enquiring minds want to know!!!
>
> Steve
> —
> Department of Computing, Macquarie University
> http://web.science.mq.edu.au/~cassidy
>
> > On 25 Aug 2016, at 9:54 PM, Steve Cassidy 
> wrote:
> >
> > Nah, definitely baby steps…
> >
> > so, in the repo you point to there seems to be an error in the
> Dockerfile, the ENV line should use the var=value syntax to have more than
> one setting on one line (maybe that’s changed recently in docker).
> >
> > with this I built a new docker image, when I run my first tool it takes
> an age while it’s installing the deps, then it crashes with:
> >
> > Traceback (most recent call last):
> >  File 
> > "/export/galaxy-central/database/job_working_directory/000/1/set_metadata_QUJQLD.py",
> line 1, in 
> >from galaxy_ext.metadata.set_metadata import set_metadata;
> set_metadata()
> >  File "/galaxy-central/lib/galaxy_ext/metadata/set_metadata.py", line
> 23, in 
> >from sqlalchemy.orm import clear_mappers
> > ImportError: No module named sqlalchemy.orm
> >
> > and the output:
> >
> > discarding /galaxy-central/tool_deps/_conda/bin from PATH
> > prepending 
> > /export/galaxy-central/database/job_working_directory/000/1/conda-env/bin
> to PATH
> > discarding /galaxy-central/tool_deps/_conda/bin from PATH
> > prepending 
> > /export/galaxy-central/database/job_working_directory/000/1/conda-env/bin
> to PATH
> >
> > I’m guessing this is some kind of conflict between python versions in
> and out of conda environments? Surely sqlalchemy would be installed for
> Galaxy to work?
> >
> > I’ll try to dig around this in the morning but if it rings a bell…
> >
> > Steve
> > —
> > Department of Computing, Macquarie University
> > http://web.science.mq.edu.au/~cassidy
> >
> >> On 25 Aug 2016, at 8:43 PM, Björn Grüning 
> wrote:
> >>
> >> Hi Steve,
> >>
> >> you call this baby-steps? I think this is huge! :)
> >>
> >> All what you are missing is to enable conda in Galaxy.
> >> Look at Gregs new flavour which is entirely Conda/Galaxy based.
> >>
> >> You need to enable these env vars to make Galaxy conda enabled:
> >>
> >> https://github.com/gregvonkuster/docker-galaxy-csg/blob/mast
> er/Dockerfile#L9
> >>
> >> Hope this helps,
> >> Bjoern
> >>
> >> Am 25.08.2016 um 12:32 schrieb Steve Cassidy:
> >>> Hi all,
> >>> I’m making baby steps towards having a repeatable installation for my
> >>> tools.  But I’m now stuck,