Re: [galaxy-dev] ToolShed test failure: NotFound: cannot find 'ucsc_display_sites' while searching for 'APP.config.ucsc_display_sites'
On Wed, Sep 10, 2014 at 7:55 PM, Nate Coraor n...@bx.psu.edu wrote: Hi Peter, This was due to a bug I introduced last week, which I've just fixed in d1f6d05. Sorry for the trouble. --nate Thanks - I'll check back in a day or two once the tests have run again. Peter ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Incorrect revision getting referenced in a complex tool dependency - why?
Hi Melissa, a few remarks to your wrappers, hopefully it will fix a few issues. * If you put your python files and your java files next to your wrapper you do not need to install them. I think you can remove the tool_dependency file and it should work. * if you stick to this approach you should rename JAVA_JAR_PATH to XENA_JAR_PATH or something like this * do you really need the dependencies in the other repositories? Dependencies are used to access binaries or libaries from other installations, as far as I could see you are accessing a local port or? So no dependency * Question: do you need the server running all the time, or can you that it during the tool execution (find, import)? We need a proper mechanism to support such things like servers (on some ports). You will here have the issue that multiple users can't start a server at once. We need to get devteam help here. Would you be so kind and create a trello card for it? Okay, I really need debugging ideas on this one. I have three repositories I'm developing under the test toolshed. They're named start_xena, xena_import and xena_find_datasets (they're all under visualization). start_xena contains a simple tool dependency to a package named installXena. xena_import and xena_find_datasets contain complex dependencies to installXena. I've installed these tools on two computers. On one, everything works great - amazingly well, in fact! Kudos, Development Team! On the other computer, the env.sh files associated with the complex dependencies keep referencing the wrong version of start_xena/installXena. Here are the gory details. The start_xena tool is installed in testtoolshed.g2.bx.psu.edu/repos/melissacline/start_xena/82755b0ee5a5/start_xena. I'm a bit confused about the revision part of the path, because the latest revision is different (75c7d80df9c1), and I have uninstalled and re-installed the tool since its last update. Its package, installXena, is installed under tool_dependencies at tool_dependencies/installXena/1.0/melissacline/start_xena/82755b0ee5a5/. That directory contains all the files I'd expect to be there, and its env.sh file contains all the environment variables I'd intended to set. So far, so good. xena_import is installed on my computer at testtoolshed.g2.bx.psu.edu/repos/melissacline/xena_import/dc42b6bbc22b/xena_import. Its tool_dependencies.xml reference installXena under start_xena as: ?xml version=1.0? tool_dependency package name=installXena version=1.0 repository toolshed=http://testtoolshed.g2.bx.psu.edu; name=start_xena owner=melissacline changeset_revision=82755b0ee5a5/ /package /tool_dependency (Aside: is it necessary to have the changeset_revision in there? I'm a bit worried about the maintenance task of updating it for all of my dependent tools every time I update start_xena, but as I'll explain, it's not clear that this revision info is getting used). The tool dependency dir for xena_import is at tool_dependencies/installXena/1.0/melissacline/xena_import/dc42b6bbc22b/. Its env.sh reads: if [ -f /Users/melissacline/src/galaxy-dist/tool_dependencies/installXena/1.0/melissacline/start_xena/0676a227dbc6/env.sh ] ; then . /Users/melissacline/src/galaxy-dist/tool_dependencies/installXena/1.0/melissacline/start_xena/0676a227dbc6/env.sh ; fi Notice that the wrong revision number is in there. The 06 revision was an older one. Needless to say, the files and environment variables I need aren't in the 06 directory. Where does this incorrect revision number come from? I've deleted all the 06 directories, repeatedly. I've deleted and reinstalled the tools, and verified that after deletion, the directories in question were in fact gone. I've tried resetting the metadata for these tools under the Galaxy Admin menu. Now I need new ideas. As I mentioned, all of this works beautifully on a second computer. It's as if the first Galaxy installation, on the first computer, got stuck with some outdated information, and I haven't figured out how to clear it out. I don't know but you should remove the toolshed= and the revision= from your XML files. These fields will be automatically filled by the toolshed (inserting the latest tip version of your dependencies and the current toolshed url). Hope this helps a little bit! Bjoern Thanks! Melissa ___ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ To search
Re: [galaxy-dev] no capsule export from a local tool shed
Christophe, Unfortunately, exporting a capsule without a proxy in front of the tool shed will fail to find dependencies if the dependencies were defined with the proxy in place. One solution would be to re-upload the dependency definitions without using the proxy, leaving the changeset_revision and toolshed attributes undefined. This will make the tool shed recalculate tool shed URLs and changeset revisions for the dependency relationships, and the capsule export should then find them. --Dave B. On 09/10/2014 12:11 PM, Christophe Antoniewski wrote: I am replying to myself to report limited progresses... : if we run the tool shed server without apache, the export capsule job works, except that the repository dependencies are not seen (no Export repository dependencies? checkbox to check). Without this new layer of complication, we would leave apache which is not really required for tool development in our local toolshed. But Export repository dependencies matters... Sure we are missing something around Apache and tool_shed_wsgi.ini configuration, but still lost.. Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr mailto:christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax+33 1 44 27 34 45 Mobile+33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.org/ 2014-09-08 19:24 GMT+02:00 Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr mailto:christophe.antoniew...@snv.jussieu.fr: Hi, Here is a question maybe to Greg: Since the GCC2014 we started a local toolshed following the instructions in http://gregvonkuster.org/galaxy-tool-shed-framework-building-galaxy-tools/ It works nicely, except that today I tried to export repository capsules (export this revision) from the local toolshed and it returns the following error (see below). I cannot remember whether I had ever tested this particular action since the local tool shed set up. Thus I even cannot say whether the bug is due to an original misconfiguration or it happened later on. I can add that the local toolshed is served by apache with rewriting rules (I am saying this because in addition it is not possible to download repositories as gz archives etc... and suspect that there is maybe a problem, in addition, with the apache config). Any help appreciated ! Regards Christophe --- URL: http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f Module galaxy.web.framework.middleware.error:*149* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#app_iter *=* self*.*application*(*environ*,* sr_checker*)*| Module paste.debug.prints:*106* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#environ*,* self*.*app*)*| Module paste.wsgilib:*543* in |intercept_output| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#app_iter *=* application*(*environ*,* replacement_start_response*)*| Module paste.recursive:*84* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*application*(*environ*,* start_response*)*| Module paste.httpexceptions:*633* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*application*(*environ*,* start_response*)*| Module galaxy.web.framework.base:*132* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*handle_request*(* environ*,* start_response *)*| Module galaxy.web.framework.base:*190* in |handle_request| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#body *=* method*(* trans*,* kwargs *)*| Module galaxy.webapps.tool_shed.controllers.repository:*1249* in |export| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#repositories_archive_filename *=* os*.*path*.*basename*(* repositories_archive*.*name *)*| *AttributeError: 'NoneType' object has no attribute 'name'* Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05
Re: [galaxy-dev] Keeping Galaxy up to date
Hi Sebastian, As for Galaxy Main (usegalaxy.org), our process is automated with Ansible, the playbook for which can be found here: https://github.com/galaxyproject/usegalaxy-playbook A bit of documentation on what you should look for (new versions of universe_wsgi.ini.sample, datatypes_conf.xml.sample, etc.) would certainly be helpful, so I'll expand the keeping up to date page on getgalaxy.org into a new page and add more details. On Tue, Sep 9, 2014 at 6:55 AM, Sebastian Schaaf sch...@ibe.med.uni-muenchen.de wrote: Hi Thomas, We had this topic at the GCC this year, especially within the Galaxy Admins BoF. The truth is (please correct me anyone if this is not the case anymore!) that you are touching an unresolved point. Keeping track of tools, settings etc. across the versions is not given. People have their 'home-brew' solutions for this, e.g. keeping a (maybe virtual) machine in spare in order to invest several hours up to some days to test (with or without participation of the users) applicability to local constraints/histories/workflow/tools. The more testing is automated and the less users (or non-default pieces) the faster the update procedure can be. But there are also instances which did not receive updates for months or even years. On our side we will be facing reality within the next two weeks as we really need the update. Although preconditions are pretty good (few users, not that deep modifications, high grade of automation) we expect some issues. happy to have a virtualized environment... To wrap up my answer in a nutshell: no, there is no best practice guide and no migration tool, but every single contribution is warmly welcome :). It would be *very* interesting how updates are handled at Galaxy Main...? Cheers, Sebastian (very interested in further feedback) Hello, I try to keep our Galaxy instance up to date. Very often, some tools disappear and other do not work anymore. This breaks some users workflows. I may miss something. Is there a best update pratice to keep a Galaxy instance and the tool-sheds fully functionnal ? Regards, Thomas -- Thomas Bellembois, Network and System Administrator, IGFL (France) http://perso.ens-lyon.fr/thomas.bellembois - +33 4 26 73 13 67 (IGFL internal IT doc: http://itdoc.igfl.ens-lyon.fr/itdoc) ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Keeping Galaxy up to date
Hi Nate, Thank you very much for enlightening me - I tried to get an impression on Ansible playbooks for the last two minutes and I am really exited about it. Principle and syntax are close to what we are doing in plain BASH plus config files, but the respective scripts are for sure more complex, because we have to write explicitly the tasks which are 'ready to use' modules in Ansible (and I really like YAML btw :) ). I am really looking forward to your updated article on the wiki - in the meantime I will forward the verve to my colleagues ;). Maybe we manage to switch on the playbook principle before the planned update. Cheers thanks again, Sebastian Hi Sebastian, As for Galaxy Main (usegalaxy.org), our process is automated with Ansible, the playbook for which can be found here: https://github.com/galaxyproject/usegalaxy-playbook A bit of documentation on what you should look for (new versions of universe_wsgi.ini.sample, datatypes_conf.xml.sample, etc.) would certainly be helpful, so I'll expand the keeping up to date page on getgalaxy.org into a new page and add more details. On Tue, Sep 9, 2014 at 6:55 AM, Sebastian Schaaf sch...@ibe.med.uni-muenchen.de wrote: Hi Thomas, We had this topic at the GCC this year, especially within the Galaxy Admins BoF. The truth is (please correct me anyone if this is not the case anymore!) that you are touching an unresolved point. Keeping track of tools, settings etc. across the versions is not given. People have their 'home-brew' solutions for this, e.g. keeping a (maybe virtual) machine in spare in order to invest several hours up to some days to test (with or without participation of the users) applicability to local constraints/histories/workflow/tools. The more testing is automated and the less users (or non-default pieces) the faster the update procedure can be. But there are also instances which did not receive updates for months or even years. On our side we will be facing reality within the next two weeks as we really need the update. Although preconditions are pretty good (few users, not that deep modifications, high grade of automation) we expect some issues. happy to have a virtualized environment... To wrap up my answer in a nutshell: no, there is no best practice guide and no migration tool, but every single contribution is warmly welcome :). It would be *very* interesting how updates are handled at Galaxy Main...? Cheers, Sebastian (very interested in further feedback) Hello, I try to keep our Galaxy instance up to date. Very often, some tools disappear and other do not work anymore. This breaks some users workflows. I may miss something. Is there a best update pratice to keep a Galaxy instance and the tool-sheds fully functionnal ? Regards, Thomas -- Thomas Bellembois, Network and System Administrator, IGFL (France) http://perso.ens-lyon.fr/thomas.bellembois - +33 4 26 73 13 67 (IGFL internal IT doc: http://itdoc.igfl.ens-lyon.fr/itdoc) ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ -- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich Marchioninistr. 15, K U1 (postal) Marchioninistr. 17, U 006 (office) D-81377 Munich (Germany) Tel: +49 89 2180-78178 ___ 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: http://lists.bx.psu.edu/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] API : Max retries exceeded
Hi, I wrote a script which need to retrieve a list of all users on our production instance. It seems that we have too many users (325) :P bioblend.galaxy.client.ConnectionError: HTTPConnectionPool(host='galaxy.sb-roscoff.fr', port=8080): Max retries exceeded with url: /api/users?key=fd420zefff9a9df586210fd8c8452d98 (Caused by class 'socket.error': [Errno 111] Connection refused): None My script is running on an test instance which have less users. Is there a way to set this threshold ? Thanks Gildas PS : don't try my api_key, little hacker, it's a fake :P ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] BAMtools in Galaxy
Derek: Just to let you know that I just wrapped BAMTools for Galaxy: GitHub - https://github.com/nekrut/bamtools GalaxyToolShed - https://toolshed.g2.bx.psu.edu/view/anton/bamtools Galaxt Test Server - https://test.galaxyproject.org (look for BAMTools on the left pane). We will roll them out on the main site soon. Thanks for a great package! anton -- Anton Nekrutenko Professor of Biochemistry and Molecular Biology http://nekrut.bx.psu.edu (814) 826-3051 ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] problems with the varscan somatic tool
Dear Galaxy team, i tried to run the varscan somatic tool from fcaramia on two pileup files but i got the following error: Unknown Input: COMMAND::java -jar /home/karin/galaxy/dependency_dir/VarScan/2.3.5/fcaramia/varscan/51969e284317/jars/VarScan.v2.3.5.jar somatic The command was the following: Job Command-Line:perl /home/karin/shed_tools/ toolshed.g2.bx.psu.edu/repos/fcaramia/varscan/51969e284317/varscan/varscan_somatic.pl COMMAND::java -jar $JAVA_JAR_PATH/VarScan.v2.3.5.jar somatic NORMAL::/home/karin/galaxy-dist/database/files/000/dataset_107.dat TUMOR::/home/karin/galaxy-dist/database/files/000/dataset_109.dat OUTPUT::/home/karin/galaxy-dist/database/files/000/dataset_145.dat OPTION::--min-coverage 8 OPTION::--min-coverage-normal 8 OPTION::--min-coverage-tumor 8 OPTION::--min-var-freq 0.1 OPTION::--min-freq-for-hom 0.75 OPTION::--normal-purity 1.0 OPTION::--tumor-purity 1.0 OPTION::--p-value 0.99 OPTION::--somatic-p-value 0.05 OPTION::--strand-filter 1 OPTION::--validation 0 OPTION::--output-vcf 1 I also tried to change the varscan_somatic.xml file in such a way that i removed the COMMAND:: tags etc. and used it without the varscan_somatic.pl file. After doing that, the tool ran without errors but i obtained empty files. Redoing the same command on my local computer ran properly and i obtained the wanted outputs: java -jar $JAVA_JAR_PATH/VarScan.v2.3.5.jar somatic /home/karin/galaxy-dist/database/files/000/dataset_107.dat /home/karin/galaxy-dist/database/files/000/dataset_109.dat dataset_131.dat --output-snp dataset_131.dat --output-indel dataset_132.dat --min-coverage 8 --min-coverage-normal 8 --min-coverage-tumor 8 --min-var-freq 0.1 --min-freq-for-hom 0.75 --normal-purity 1.0 --tumor-purity 1.0 --p-value 0.99 --somatic-p-value 0.05 --strand-filter 1 2 testlog in dataset_131.dat the snps, indels: dataset_132.dat, and some information (varscan directs this info on stderr) in testlog. Any idea how to fix that? i appreciate any information on how this may be fixed! Thanks a lot and best wishes, Karin ___ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] no capsule export from a local tool shed
Dave, Thank you very much, it worked indeed. The gz export does not work yet, but this is apparently now due to a problem with mercurial (An error occurred while processing your request: - Archive type not allowed: gz). Anyway, this is not a main issue and we are going to be able to focus on the tools, without apache. Thank thank thank Chris Christophe Antoniewski http://sciencesenmarche.org/ Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax +33 1 44 27 34 45 Mobile +33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.org/ 2014-09-11 15:18 GMT+02:00 Dave Bouvier d...@bx.psu.edu: Christophe, Unfortunately, exporting a capsule without a proxy in front of the tool shed will fail to find dependencies if the dependencies were defined with the proxy in place. One solution would be to re-upload the dependency definitions without using the proxy, leaving the changeset_revision and toolshed attributes undefined. This will make the tool shed recalculate tool shed URLs and changeset revisions for the dependency relationships, and the capsule export should then find them. --Dave B. On 09/10/2014 12:11 PM, Christophe Antoniewski wrote: I am replying to myself to report limited progresses... : if we run the tool shed server without apache, the export capsule job works, except that the repository dependencies are not seen (no Export repository dependencies? checkbox to check). Without this new layer of complication, we would leave apache which is not really required for tool development in our local toolshed. But Export repository dependencies matters... Sure we are missing something around Apache and tool_shed_wsgi.ini configuration, but still lost.. Chris Christophe Antoniewski Drosophila Genetics and Epigenetics Laboratoire de Biologie du Développement 9, Quai St Bernard, Boîte courrier 24 75252 Paris Cedex 05 christophe.antoniew...@upmc.fr mailto:christophe.antoniew...@upmc.fr http://bio-dev.snv.jussieu.fr/ Tel +33 1 44 27 34 39 Fax+33 1 44 27 34 45 Mobile+33 6 68 60 51 50 http://drosophile.org http://www.sciencesenmarche.org/ 2014-09-08 19:24 GMT+02:00 Christophe Antoniewski christophe.antoniew...@snv.jussieu.fr mailto:christophe.antoniew...@snv.jussieu.fr: Hi, Here is a question maybe to Greg: Since the GCC2014 we started a local toolshed following the instructions in http://gregvonkuster.org/galaxy-tool-shed-framework- building-galaxy-tools/ It works nicely, except that today I tried to export repository capsules (export this revision) from the local toolshed and it returns the following error (see below). I cannot remember whether I had ever tested this particular action since the local tool shed set up. Thus I even cannot say whether the bug is due to an original misconfiguration or it happened later on. I can add that the local toolshed is served by apache with rewriting rules (I am saying this because in addition it is not possible to download repositories as gz archives etc... and suspect that there is maybe a problem, in addition, with the apache config). Any help appreciated ! Regards Christophe --- URL: http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f Module galaxy.web.framework.middleware.error:*149* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#app_iter *=* self*.*application*(*environ*,* sr_checker*)*| Module paste.debug.prints:*106* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f# environ*,* self*.*app*)*| Module paste.wsgilib:*543* in |intercept_output| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#app_iter *=* application*(*environ*,* replacement_start_response*)*| Module paste.recursive:*84* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*application*(*environ*,* start_response*)*| Module paste.httpexceptions:*633* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export? repository_id=8b0bee1f52868c9echangeset_revision=73f6de7efb1f#*return* self*.*application*(*environ*,* start_response*)*| Module galaxy.web.framework.base:*132* in |__call__| | http://lbcd41.snv.jussieu.fr/toolshed/repository/export?
Re: [galaxy-dev] Installing Galaxy on Freebsd 10.0
Just a hunch, do you guys think pysam is the cause of these issues?
From: ashis...@hotmail.com
To: dannon.ba...@gmail.com
CC: galaxy-dev@lists.bx.psu.edu
Subject: RE: [galaxy-dev] Installing Galaxy on Freebsd 10.0
Date: Wed, 10 Sep 2014 19:21:33 -0500
Hi Dannon,
Thanks for the reply.
##
python --version
Python 2.7.3# cd galaxy-dist*# rm -rf eggs#python scripts/fetch_eggs.py
/*Running this command after deleting egg folder */
Fetched http://eggs.galaxyproject.org/docutils/docutils-0.7-py2.7.egg
Fetched http://eggs.galaxyproject.org/kombu/kombu-3.0.13-py2.7.egg
Fetched http://eggs.galaxyproject.org/mock/mock-1.0.1-py2.7.egg
Fetched http://eggs.galaxyproject.org/raven/raven-3.1.8-py2.7.egg
Fetched http://eggs.galaxyproject.org/Beaker/Beaker-1.4-py2.7.egg
Traceback (most recent call last):
File scripts/fetch_eggs.py, line 37, in module
c.resolve() # Only fetch eggs required by the config
File /usr/home/ec2-user/galaxy-dist/lib/galaxy/eggs/__init__.py, line 345,
in resolve
egg.resolve()
File /usr/home/ec2-user/galaxy-dist/lib/galaxy/eggs/__init__.py, line 195,
in resolve
return self.version_conflict( e.args[0], e.args[1] )
File /usr/home/ec2-user/galaxy-dist/lib/galaxy/eggs/__init__.py, line 226,
in version_conflict
r = pkg_resources.working_set.resolve( ( dist.as_requirement(), ), env,
egg.fetch )
File /usr/home/ec2-user/galaxy-dist/lib/pkg_resources.py, line 565, in
resolve
raise DistributionNotFound(req) # XXX put more info here
pkg_resources.DistributionNotFound: PyYAML==3.10
==
I ran the command again without deleting the egg folder and this is what I
got
==#python
scripts/fetch_eggs.py /*Running this command 2nd time without deleting
egg folder */
Warning: MarkupSafe (a dependent egg of Mako) cannot be fetched
Warning: pycrypto (a dependent egg of Fabric) cannot be fetched
Warning: pytz (a dependent egg of Babel) cannot be fetched
Fetched http://eggs.galaxyproject.org/paramiko/paramiko-1.11.1-py2.7.egg
One of Galaxy's managed eggs depends on something which is missing, this is
almost certainly a bug in the egg distribution.
Dependency paramiko requires pycrypto=2.1,!=2.4
Traceback (most recent call last):
File scripts/fetch_eggs.py, line 37, in module
c.resolve() # Only fetch eggs required by the config
File /usr/home/ec2-user/galaxy-dist/lib/galaxy/eggs/__init__.py, line 345,
in resolve
egg.resolve()
File /usr/home/ec2-user/galaxy-dist/lib/galaxy/eggs/__init__.py, line 168,
in resolve
dists = pkg_resources.working_set.resolve( (
self.distribution.as_requirement(), ), env, self.fetch )
File /usr/home/ec2-user/galaxy-dist/lib/pkg_resources.py, line 569, in
resolve
raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (paramiko 1.11.1
(/usr/home/ec2-user/galaxy-dist/eggs/paramiko-1.11.1-py2.7.egg),
Requirement.parse('pycrypto=2.1,!=2.4'))=
Can you think of any other reasons? It works well on OS X and Ubuntu.
-Ashish
Date: Wed, 10 Sep 2014 16:59:13 -0400
Subject: Re: [galaxy-dev] Installing Galaxy on Freebsd 10.0
From: dannon.ba...@gmail.com
To: ashis...@hotmail.com
CC: galaxy-dev@lists.bx.psu.edu
Hey Ashish,
We have an open issue to sort out exactly why/how this happens, but a quick fix
for many users is just to remove your eggs/ folder and all eggs and re-run
`python scripts/fetch_eggs.py`. Give that a shot, but do let me know if it
doesn't' work.
On Wed, Sep 10, 2014 at 4:54 PM, ashish damania ashis...@hotmail.com wrote:
# sh run.shSome eggs are out of date, attempting to fetch...Warning: setuptools
(a dependent egg of sqlalchemy-migrate) cannot be fetchedWarning: simplejson (a
dependent egg of bioblend) cannot be fetchedsimplejson 2.1.1 couldn't be
downloaded automatically. You can trybuilding it by hand with: python
scripts/scramble.py -e simplejsonFetch failed.Traceback (most recent call
last): File
/usr/home/ec2-user/galaxy-dist/lib/galaxy/webapps/galaxy/buildapp.py, line
38, in app_factory from galaxy.app import UniverseApplication File
/usr/home/ec2-user/galaxy-dist/lib/galaxy/app.py, line 12, in module from
galaxy.visualization.data_providers.registry import DataProviderRegistry File
/usr/home/ec2-user/galaxy-dist/lib/galaxy/visualization/data_providers/registry.py,
line 2, in module from galaxy.visualization.data_providers import genome
File
/usr/home/ec2-user/galaxy-dist/lib/galaxy/visualization/data_providers/genome.py,
line 17, in module from pysam import !csamtools, ctabix File
