Re: [galaxy-dev] Workflow Compatibility
Hi Katherine:
This is outside my experience… but I wonder if you could try using a formulaic
name for the output (output1, output2, output3, output4) rather than base the
output name on the input file’s name.
Maybe someone else has some experience with something like this?
Brad
—
Brad Langhorst, Ph.D.
Development Scientist
New England Biolabs
On Aug 26, 2016, at 2:37 PM, Katherine Beaulieu
mailto:katherine.beaulieu...@gmail.com>> wrote:
Hmm, unfortunately the paths have to be dynamically generated because this is
basically just an upload tool, but for another filesystem on your computer
other than the default (like Finder for Mac for example), in my case 'iRODS',
so its not really feasible to have something like a file browser or to hard
code the paths.
Although I do have a dynamic select list working at the moment and do get
multiple files outputted into my history, when I try to use one of the files I
uploaded, in a workflow, I get this error:
File '/home/katie/galaxy/lib/galaxy/workflow/run.py', line 308 in
replacement_for_connection
raise Exception( message )
Exception: Workflow evaluation problem - failed to find output_name
__new_primary_file_output|foo.txt__ in step_outputs {'output':
}
And when I look in the database (table workflow_step_connection) every other
normal file's output_name is the name of the output variable from the tool
config file, for example if the parameter is mailto:langho...@neb.com>> wrote:
Hi:
Yes - let’s say you have hard coded paths… you could put those into a select
list pretty easily (just have the paths embedded like the bowtie wrapper does
the paired-end vs. single-end select list).
You might also want to consider a table lookup though.
The bowtie wrapper does that for reference genomes.
You can make your own lookup table to refer to whatever files you want, which
would allow you to update paths without installing new version of the tool.
brad
—
Brad Langhorst, Ph.D.
Development Scientist
New England Biolabs
On Aug 26, 2016, at 1:06 PM, Katherine Beaulieu
mailto:katherine.beaulieu...@gmail.com>> wrote:
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
mailto:langho...@neb.com>> 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
mailto: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
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 > xy2/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/gala > xy2/lib/galaxy/util/pastescript/loadwsgi.py", line 94, in fix_call >
[galaxy-dev] Loading a GUI on galaxy
Hello All, 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 load the GUI on a local instance of galaxy. But when i am trying to access the galaxy server through a remote connection, this GUI is not able to load on remote desktop. Any comments or suggestions would be of great interest ! -- Regards, Lijo 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/
[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 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] Workflow Compatibility
Hmm, unfortunately the paths have to be dynamically generated because this
is basically just an upload tool, but for another filesystem on your
computer other than the default (like Finder for Mac for example), in my
case 'iRODS', so its not really feasible to have something like a file
browser or to hard code the paths.
Although I do have a dynamic select list working at the moment and do get
multiple files outputted into my history, when I try to use one of the
files I uploaded, in a workflow, I get this error:
File '/home/katie/galaxy/lib/galaxy/workflow/run.py', line 308 in
replacement_for_connection
raise Exception( message )
Exception: Workflow evaluation problem - failed to find output_name
__new_primary_file_output|foo.txt__ in step_outputs {'output':
}
And when I look in the database (table workflow_step_connection) every
other normal file's output_name is the name of the output variable from the
tool config file, for example if the parameter is wrote:
> Hi:
>
>
> Yes - let’s say you have hard coded paths… you could put those into a
> select list pretty easily (just have the paths embedded like the bowtie
> wrapper does the paired-end vs. single-end select list).
>
> You might also want to consider a table lookup though.
> The bowtie wrapper does that for reference genomes.
> You can make your own lookup table to refer to whatever files you want,
> which would allow you to update paths without installing new version of the
> tool.
>
>
>
> brad
> —
> Brad Langhorst, Ph.D.
> Development Scientist
> New England Biolabs
>
>
>
>
> On Aug 26, 2016, at 1:06 PM, Katherine Beaulieu <
> katherine.beaulieu...@gmail.com> wrote:
>
> 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] Workflow Compatibility
Hi: Yes - let’s say you have hard coded paths… you could put those into a select list pretty easily (just have the paths embedded like the bowtie wrapper does the paired-end vs. single-end select list). You might also want to consider a table lookup though. The bowtie wrapper does that for reference genomes. You can make your own lookup table to refer to whatever files you want, which would allow you to update paths without installing new version of the tool. brad — Brad Langhorst, Ph.D. Development Scientist New England Biolabs On Aug 26, 2016, at 1:06 PM, Katherine Beaulieu mailto:katherine.beaulieu...@gmail.com>> wrote: 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 mailto:langho...@neb.com>> 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 mailto: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
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 "/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",
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 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
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 >>> "/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 >>> "/r
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" > 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 lists, please use the interface at: > https://lists.galaxyproject.org/ > > To search Galaxy mailing lists use th
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 "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 all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the
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 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
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
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
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
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 mailto: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] 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 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
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 mailto:katherine.beaulieu...@gmail.com>> wrote: On Fri, Aug 26, 2016 at 10:42 AM, Katherine Beaulieu mailto: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 mailto:p.j.a.c...@googlemail.com>> 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 mailto:katherine.beaulieu...@gmail.com>> 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
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
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
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
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
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, so help would be appreciated. > >>> > >>> I have a tool that works and is in t
