Hello,
I've been spending a bit of time looking over Data Sources
<https://wiki.galaxyproject.org/Admin/Internals/DataSources> for Galaxy.
I've been thinking about designing a tool in Galaxy, similar to a Data
Sources tool, which would take as input a file defining a list of URLs to
import into Galaxy, along with some user credentials. In this sense it
would be similar to the GenomeSpace
<https://bitbucket.org/galaxy/galaxy-dist/src/579d211c2b0fa8ef4195930cb999ed…>
importer tool.
However, instead of just exporting a set of files to a user's history, I'd
like to be able to also automatically group these files into a dataset
collection. I would also like to be able to link to these files instead of
creating copies (which I think I can only do through a Data Library am I
correct?). Ideally, I'd like to be able to use this tool as the first step
in a workflow, which would allow me to import and structure the data needed
for the rest of the workflow.
Does anyone have any experience writing a similar tool? Is this possible
in the current Galaxy version?
Thanks,
Aaron
Main and Test toolsheds are not resolving properly tonight...
{u'status': u'error', u'error': u'Error attempting to retrieve
installation information from tool shed
http://testtoolshed.g2.bx.psu.edu for revision 7511823bdea1 of
repository bedtools owned by iuc: <urlopen error [Errno -3] Temporary
failure in name resolution>'}
Cheers,
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
evan(a)msi.umn.edu
boll0107(a)umn.edu
Hi all,
I'm running galaxy-central as my development server, and noticed what
to me is a regression with repeat parameters,
e.g. https://github.com/peterjc/pico_galaxy/blob/master/tools/clc_assembly_cell/…
Read group:
[+ insert read group]
* 1: Read Group
* 2: Read Group
which on clicking becomes:
Read group:
[+ insert read group]
* 2: Read Group
* 1: Read Group
This to me is upside down, the current behaviour on galaxy-dist is
more natural (and also pluralises the group heading):
Read Groups
* Read Group 1
[Add new Read Group]
which on clicking becomes:
Read Groups
* Read Group 1
* Read Group 2
[Add new Read Group]
Is this a deliberate change? If so, why?
Peter
Hi,
As we have arranged an sftp upload system through ftp port for our Galaxy
instance, we would need to customize the Upload File tool form, so that a
few more line explain how-to-do in the FTP section of the form, in addition
to the "This Galaxy server allows you to upload files via FTP. To upload
some files, log in to the FTP server at 127.0.0.1 using your Galaxy
credentials (email address and password)."
I dug into
/home/galaxy/galaxy-dist/static/scripts/mvc/upload/upload-ftp.js
and
/home/galaxy/galaxy-dist/static/scripts/packed/mvc/upload/upload-ftp.js
but the changes I tried into these files do not show up in the tool form.
If someone can indicate the right way to intercept this content and enrich
it as mentioned above, I would be grateful !
Cheers
Chris
Christophe Antoniewski
Drosophila Genetics and Epigenetics
Institut de Biologie Paris Seine
<http://www.ibps.upmc.fr/fr/Recherche/umr-biologie-developpement/genetique-e…>
9, Quai St Bernard, Boîte courrier 24
75252 Paris Cedex 05
Tel +33 1 44 27 34 39
Fax +33 1 44 27 34 45
Mobile +33 6 68 60 51 50
christophe.antoniewski(a)upmc.fr
http://drosophile.org
Hi all,
I was wondering if there were any existing implementations of, or any plans
for, a drill down selection component that supports thousands of items? For
example a taxonomy based drill down.
Thanks,
Andrew
Hi,
I have a Bioconductor package which depends on R 3.1.1 , so I think I cannot use the "setup_r_environment" trick.
I already got a tool_dependency.xml working that installs R 3.1.1 and the necessary Bioconductor packages using bioclite method (see attachment). Now my question is:
* I would like to split up this into two steps as I don't want to trigger the compilation of new R environment every time I when I need to just update the Bioconductor package....the question is: how to do such things in general? How can I access the INSTALL_DIR of another tool from within another tool_dependency.xml? If I can do this, then my problem is solved.
Thanks!
Pieter Lukasse
Wageningen UR, Plant Research International
Department of Bioinformatics (Bioscience)
Wageningen Campus, Building 107, Droevendaalsesteeg 1, 6708 PB,
Wageningen, the Netherlands
T: +31-317481122;
M: +31-628189540;
skype: pieter.lukasse.wur
http://www.pri.wur.nl<http://www.pri.wur.nl/>
Hello,
I want to rename ouput datasets in a workflow in such a way that the name
contains the name of the input dataset. I could not find instructions in
the manual (and this info is missing in the Workflow editor - would be
really helpful there!).
I tried #{input}, e.g. "stats on: #{input}" (with no quotes), but I keep
getting just "stats on:" The variable is empty. When I use ${input}, I get
a variable field in the workflow form (I do not want this).
My G. instance: Galaxy changeset: d1e1beeb532239250396dd8fbdc0156508c6744e
<https://bitbucket.org/galaxy/galaxy-central/commits/d1e1beeb532239250396dd8…>
Can anyone help me, please?
Jan
Devteam:
On 10/23 an update was posted to package_picard_1_56_0 that breaks
tool Picard. Since 10/23, picard depends on package_picard_1_56_0,
which in turn depends on picard 1.122.0, but that dependency makes
absolutely no sense.
Now when I run PairedReadMateFixer I get:
####################
## exit code=1; stdout=
Error: Unable to access jarfile /FixMateInformation.jar
####################
which appears to be caused by bad paths
I don't understand toolshed logic for revisions: when I install tools
with very specific revisions, the tool depends on very specific
revisions of other tools. However, when I install a tool that depends
on a package_*, the package has revision information, but it is
ignored in favor of installing the LATEST revision of the package. If
someone posts a buggy revision of a package_* to the toolshed, there
is no way to avoid installing it until a fixed version is posted in
its place.
For example, when I run:
python ./scripts/api/install_tool_shed_repositories.py --api
XXXXXXXXXX --local http://127.0.0.1:8080 --url
http://toolshed.g2.bx.psu.edu --name package_picard_1_56_0 --owner
devteam --revision 61e41d21cb6f --tool-deps --repository-deps
--panel-section-name "Other (Main Tool Shed)"'
I expect package_picard_1_56_0:61e41d21cb6f to be installed, but
instead I get package_picard_1_56_0:4a49481f29e7:
#######
Response
--------
/api/tool_shed_repositories/03501d7626bd192f
name: package_picard_1_56_0
status: Installed
tool_shed_status: {u'latest_installable_revision': u'True',
u'revision_update': u'False', u'revision_upgrade': u'False',
u'repository_deprecated': u'False'}
deleted: False
ctx_rev: 1
error_message:
dist_to_shed: False
tool_shed: toolshed.g2.bx.psu.edu
installed_changeset_revision: 4a49481f29e7
uninstalled: False
owner: devteam
changeset_revision: 4a49481f29e7
id: 03501d7626bd192f
includes_datatypes: False
#######
Why ignore the package revisions?
Btw, I did find an alternate (and working) package_picard_1_56_0 in
the test toolshed, but why do I need to depend on the test toolshed
for a production environment?
-Evan Bollig
Research Associate | Application Developer | User Support Consultant
Minnesota Supercomputing Institute
599 Walter Library
612 624 1447
evan(a)msi.umn.edu
boll0107(a)umn.edu
Hello Galaxy Community,
*Galaxy Mailing Lists are moving!*
During the week of November 17-21, 2014, Galaxy mailing lists (including
this one) will be migrated from lists.bx.psu.edu to lists.galaxyproject.org
.
This transition should be largely transparent to you, but there are a few
things to be aware of:
- List sender addresses and headers will change to reflect the updated
domain: from bx.psu.edu to galaxyproject.org. Existing email filters you
have set up may require adjustments.
- Posts from lists.galaxyproject.org could be categorized as spam until
you train your filtering method.
- Mailing list archives and posting functionality will be briefly
inaccessible during the migration.
- The prior bx.psu.edu list posting email addresses will continue to
accept email, which will be forwarded to the new list addresses.
As always, you can manage your subscription for any Galaxy mailing list by
following the link instructions at the bottom of this announcement. If you
should notice any problems after the migration, please do not hesitate to
let us know, via email to both "<list>-owner(a)lists.galaxyproject.org"
(after the move) and to myself.
Thanks,
--nate, and the Galaxy Team
Hello all,
Because Galaxy uses the upload tool internally for the inputs for
function tests, it is possible to bundle gzipped versions of test
inputs which saves space. For example,
https://github.com/peterjc/pico_galaxy/blob/master/tools/clc_assembly_cell/…
However, what I have just found is that this does not work for
gzipped files as test outputs. Rather Galaxy seems to compare
the (uncompressed) output from the tool to the expected output
file as it is (i.e. still compressed). e.g.
https://github.com/peterjc/pico_galaxy/commit/c8adfdf5d1f48c00ac72df967d2be…
(I have only tested adding/removing the gzip compression on the
output file locally)
Is this deliberate?
Peter
P.S.
I wanted point at the TravisCI output for that commit and its parent
to show the output,
- https://travis-ci.org/peterjc/pico_galaxy/builds/40203652
- https://travis-ci.org/peterjc/pico_galaxy/builds/40202182
However there appears to be an egg issue with the current
galaxy-central branch:
$ python scripts/fetch_eggs.py
Warning: MarkupSafe (a dependent egg of Mako) cannot be fetched
Traceback (most recent call last):
File "scripts/fetch_eggs.py", line 46, in <module>
c.resolve() # Only fetch eggs required by the config
File "/home/travis/build/peterjc/pico_galaxy/galaxy-central-master/lib/galaxy/eggs/__init__.py",
line 347, in resolve
egg.resolve()
File "/home/travis/build/peterjc/pico_galaxy/galaxy-central-master/lib/galaxy/eggs/__init__.py",
line 192, in resolve
if e.args[1].key != e.args[0].key:
IndexError: tuple index out of range