September 2013 - galaxy-dev - lists.galaxyproject.org

[RFC] Storing of tarballs and patches for tool_dependencies to enable reproducibility
by Bjoern Gruening 17 Sep '13

17 Sep '13

Hi, I want to start a discussion about the storage of tarballs to guarantee the availability to some degree. Currently, I store most of my tarballs in my github account, if I do not trust the official ftp/http server. Anyone has the same problems/concerns? Is there an official guideline/recommendation? James raised that topic in one thread ... and I really want to see that happen, to some extend: http://dev.list.galaxyproject.org/tool-dependencies-xml-format-tp4661410p46… I know it is an ambiguous task, but if Galaxy will be an reproducible system we need to think about that issue, discuss it and make a clear statement how far we want to go, what is feasible and what is not. Downstream it has many implications, already now for a few IUC members. For example it is hard to tell tool developers about reproducible tool_dependencies if no clear statement is ever made. A few problems that I encountered during tool development: - 'no stable links': tarballs on a 'lab'-website will change there links or delete old versions of tarballs - github: I'm really not sure if the 'raw' API I use for fetching single files or tarballs from my github account is stable and will remain. I also think I can not put in GB of tarballs in my github account, but currently its the best option I have - Sometimes you need to apply patches, these need to be stored somewhere. - If I store arbitrary tarballs in my github account and the installation routine in Galaxy, the user of my tools need a huge level of trust in my work. Moreover, the IUC can hardly control that (md5 checksums, next to each tarball?) In my opinion we need a central storage, where we can put our tarballs and so one. (mirrored ...) Some ideas: Two separated tool shed areas for one account: 1. version controlled 2. non-version controlled for tarballs and redirection files/rules, to redirect old links, maybe even redirect old repositories to new ones (assuming the history is the same and so on?) FTP Server with a few limitations, like file-size and authentication to make illegal file sharings harder. Ask the github guys if they are willing to support us? Build on top of Open Data initiatives, like the Open Data Portal in Swiss: http://www.bar.admin.ch/themen/01648/?lang=en Any comments, ideas? Cheers, Bjoern

4 6

Number of Threads Tophat2/Bowtie2
by Richard Kuo 17 Sep '13

17 Sep '13

Hello, It looks like the default wrapper that comes with Galaxy for Tophat2 and Bowtie2 does not include options for selecting how many threads/cores to use. Is there an easy way to get this feature in the wrappers or do I simply need to add it to the wrapper code? I Alternatively, does anyone know of tested/debugged wrappers for Tophat2/Bowtie2 that have this feature built in? Thank you, Richard

2 1

tool_dependencies.xml format
by James Taylor 17 Sep '13

17 Sep '13

All, I've been seeing some examples of tool_depedencies.xml come across of the list, and I'm wondering if there are ways that it can be simplified. When we were first defining these features, we talked about having high level recipes for certain types of installs. This could greatly simplify things. For example, can this: <tool_dependency> <package name="requests" version="1.2.3"> <install version="1.0"> <actions> <action type="download_by_url">http://pypi.python.org/packages/source/r/requests/re quests-1.2.3.tar.gz</action> <action type="make_directory">$INSTALL_DIR/lib/python</action> <action type="shell_command">export PYTHONPATH=$PYTHONPATH:$INSTALL_DIR/lib/python && python setup.py install --home $INSTALL_DIR --install-scripts $INSTALL_DIR/bin</action> <action type="set_environment"> <environment_variable name="PYTHONPATH" action="append_to">$INSTALL_DIR/lib/python</environment_variable> <environment_variable name="PATH" action="prepend_to">$INSTALL_DIR/bin</environment_variable> </action> </actions> </install> <readme> </readme> </package> </tool_dependency> Be simplified to: <tool_dependency> <package name="requests" version="1.2.3"> <install recipe="python_package_setuptools" url="http://pypi.python.org/packages/source/r/requests/requests-1.2.3.tar.gz" /> </tool_dependency> The assumptions are: when version is not provided, it is 1.0 (we've always maintained compatibility in the past for config files so hopefully this never changes), when installing a python package the install directories and environment variables that need to be set are always the same. Similar recipes could be: autoconf: default to configure; make; make install, allow providing configuration options make_install: just make; make install; allow providing make options python_virtualenv ruby_rbenv r_package ... Basically, most of the times the steps to install a particular package are boilerplate, this would remove a ton of duplication in the recipe files. Also, a likely less popular proposal would be to go one step further, tool_dependencies.yaml: recipe: python_package_setuptools name: requests version: 1.2.3 url: http://pypi.python.org/packages/source/r/requests/requests-${version}.tar.gz -- jt

4 5

[GSoC2013] Update
by Saket Choudhary 16 Sep '13

16 Sep '13

I wrote a very short update here: http://galaxy-gsoc2013.blogspot.in/2013/09/penultimate-update.html Saket

1 0

CuffDiff read group tracking
by Matthew Paul 16 Sep '13

16 Sep '13

Hey Galaxy, I am trying to use CuffDIff with replicate analysis on a local instance. I saw that Jeremy Goecks had a solution to this problem: http://user.list.galaxyproject.org/Cuffdiff-changes-tt4655893.html#a4655901. Could I see/use this source code please? I can't really wait until the next update. Thanks, Matt Paul

2 1

Can the API add elements to a repeat parameter?
by Carlos Borroto 16 Sep '13

16 Sep '13

Hi, I'm interested on running workflows with tool definitions containing repeat inputs and arguments. I was wondering if there is a way to not have to set a fix number of elements ahead of time in the workflow. Thanks, Carlos

1 0

CILogon for Galaxy
by Yu (Marie) Ma 16 Sep '13

16 Sep '13

Hi, I have developed a thin front end client in PHP to enable CILogon authentication for Galaxy, and set up a dummy Galaxy instance demo at https://gw64.iu.xsede.org. Please let me know if this is of interest to anyone and I'd be happy share more details as well as the source. The choice of PHP instead of Python is because I was unable to find a good Python Oauth library that supports the RSA-SHA1 signature method required by CILogon's OAuth interface. Thanks Marie

1 0

Geek question re HTTP POST and Galaxy
by Ted Goldstein, Ph.D. 16 Sep '13

16 Sep '13

I've been knocking my head over this all afternoon and I was hoping to buy a vowel, use a lifeline, whatever. I'm trying to use the Ember JS framework (which is very nice) for some extensions. It relies heavily on a REST model using the same method with all of the HTTP forms including Action HTTP Verb URL Find GET /people/123 Find All GET /people Update PUT /people/123 (with the HTTP payload packed with the JSON content) Create POST /people Delete DELETE /people/123 How can I make an API function that responds to all five forms and what should be in buildapp.py? All of the code in Galaxy currently uses the kwd (keyword) parameter. But there are no keywords here. Confused, Ted

3 4

tools installed from a toolshed repository displayed in an arbitrary order
by Yulia.Arzhaeva＠csiro.au 16 Sep '13

16 Sep '13

Hello guys, After porting our Galaxy tools into a tool shed repository the tool sections got lost. I know there is a possibility to assign a repository to a section inside the tools panel when the repository is getting installed. However, we would still like to have sections inside the repository - that makes navigating the tools much neater. Also, the way shed_tool_conf.xml is populated with tools during repository installation seems arbitrary to me. Is there any way to control this, to have repository tools sorted/displayed in a certain order in Tools panel, in the very least, alphabetically? I've got many tools in my repository (and no, it is not possible to divide them into several repositories), and the way they are sorted or divided into sections makes navigating the tools much easier for a user. Thanks, Yulia

3 2

Resolved toolshed mercurial authentication issue, public name change issue remains
by Guest, Simon 16 Sep '13

16 Sep '13

Hi Greg, I finally got to the bottom of the reasons for my abort: authorization failed message when trying to push tool updates into my local toolshed using hg command line (rather than web interface), having given up for a while, and just come back to it. Since my authentication agent (apache LDAP module using corporate Active Directory) was providing bare usernames to the Toolshed, I had been relying on the remote_user_maildomain feature to turn this into an email address. However, it seems this function is not triggered when using hg command line access, so I had to change my rewrite rule which sets up the apache REMOTE_USER in my apache conf file for the toolshed, from this: RequestHeader set REMOTE_USER %{RU}e to this: RequestHeader set REMOTE_USER %{RU}e(a)agresearch.co.nz Now I can push updates directly from hg, and it's much more convenient. I didn't have to change anything in that toolshed middleware (although some temporary log messages I added there were the key for me solving the problem). However, that bug remains where I can continue to change my public name in the web user interface, even after I have created repos. I know not to do this. If there's more information you want from me to try to track down what is going wrong here, just say what you need, and I will endeavour to provide it. But for me, this is now a minor issue, so don't do anything just on my account. Thanks for your help. cheers, Simon > -----Original Message----- > From: Greg Von Kuster [mailto:greg@bx.psu.edu] > Sent: Friday, 6 September 2013 1:00 p.m. > To: Guest, Simon > Cc: galaxy-dev(a)lists.bx.psu.edu > Subject: Re: [galaxy-dev] Bug in toolshed: changing public name breaks > repo path > > Hello Simon, > > The tool shed middleware basically consists of 2 files in > ~/lib/galaxy/webapps/tool_shed/framework/middleware: hg.py which handles > authentication when pushing from the command line. The remoteuser.py file > handles remote user authentication, but I cannot guarantee it properly > handles hg push from the command line since I don't have an environment > set up that way. That would be the place to take a look though, and if > you discover problems let me know and we'll apply a patch. > > Thanks very much, > > Greg Von Kuster > > > On Sep 5, 2013, at 4:53 PM, "Guest, Simon" <Simon.Guest(a)agresearch.co.nz> > wrote: > > > Hi Greg, > > > > I just changed the public name on the web interface, where you click on > the User dropdown, and choose Public Name. Something about my environment > let it happen, when it apparently should have not been possible. > > > > I suspect the reason lies in some mismatch between my apache user > authentication and toolshed userids. See my previous email for the > details of what I've been doing with that. I don't understand the > connection between userids (email addresses) used for authentication, and > public names, which appear to be used by the mercurial server inside the > toolshed (by inference from the public name appearing in the allow_push in > the toolshed repo). Is there a layer of toolshed middleware that maps > between the two? > > > > I am going to investigate other ways of doing the authentication, as I > don't think passing in REMOTE_USER from apache is working (for me). I > would like to know how others are doing that. > > > > cheers, > > Simon > > > >> -----Original Message----- > >> From: Greg Von Kuster [mailto:greg@bx.psu.edu] > >> Sent: Friday, 6 September 2013 1:17 a.m. > >> To: Guest, Simon > >> Cc: Dave Bouvier; galaxy-dev(a)lists.bx.psu.edu > >> Subject: Re: [galaxy-dev] Bug in toolshed: changing public name > >> breaks repo path > >> > >> Hello Simon, > >> > >> > >> On Sep 4, 2013, at 5:13 PM, "Guest, Simon" > >> <Simon.Guest(a)agresearch.co.nz> > >> wrote: > >> > >>> Hi Dave, Greg, > >>> > >>> Thanks for your reply. > >>> > >>> I'm running a recently checked out stable branch. hg log shows this > >> tip: > >>> changeset: 10473:c42567f43aa7 > >>> tag: tip > >>> user: greg > >>> date: Mon Aug 19 13:19:56 2013 -0400 > >>> summary: Filter invalid objects when generating the list of > >> repository_dependencies objects that are associated with a tool shed > >> repository installed into Galaxy. > >>> > >>> I wonder if this problem is related to my more fundamental problem > >>> of > >> being unable to get mercurial push authentication working properly. > >> I care much more about that, as that's blocking me (whereas the > >> problem I reported has an easy work-around). > >> > >> Even though you've found a work-around to the problem that results > >> when you change your public user name in the tool shed after you have > >> created a repository that uses it, it is extremely important that we > >> get a fix ffor the issue committed to the tool shed code. Can you > >> let us know how you went about changing your public user name? The > >> only way we've been able to do it is by manually updaing the database > >> table record using a sql statement. If you have discovered another > >> way to do it, please let us know the steps we can take to reproduce > >> it so that we can get a fix as soon as possible. If this is, in > >> fact, a bug, then it is a very critical one. > >> > >> Thanks, > >> > >> Greg Von Kuster > >> > >> > >> > >>> Here is more information about my environment. > >>> > >>> I'm using apache for digest authentication, with the htdigest file > >> containing email addresses for usernames (so it matches what the > >> toolshed wants). It passes it through to the toolshed using > >> REMOTE_USER. (We have something like this working well for our main > >> Galaxy instance.) I can access the toolshed just fine via the web > >> interface, and I can do e.g. hg outgoing on the command line against > >> a toolshed repo to see what needs pushing. But when I try hg push, I > get abort: authorization failed. > >>> > >>> Looking inside the hgrc file inside my toolshed repo, I see it has > >>> allow_push = simon-guest (i.e. my public name, not my email address). > >>> This isn't going to match the REMOTE_USER passed in from apache, > >>> which is an email address. So I think to get this working with my > >>> authentication framework, public name has to match the email address. > >>> (I tried hacking the allow_push in hgrc to be the email address, but > >>> that didn't work.) > >>> > >>> Is anyone else using a toolshed behind apache with authentication > >> handled by apache, like this? Should I expect hg push to work in > >> this configuration, or am I outside the bounds of what has been tested > so far? > >>> > >>> Thanks for your help, much appreciated. > >>> > >>> cheers, > >>> Simon > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Dave Bouvier [mailto:dave@bx.psu.edu] > >>>> Sent: Thursday, 5 September 2013 1:07 a.m. > >>>> To: Greg Von Kuster > >>>> Cc: Guest, Simon; galaxy-dev(a)lists.bx.psu.edu > >>>> Subject: Re: [galaxy-dev] Bug in toolshed: changing public name > >>>> breaks repo path > >>>> > >>>> Simon, > >>>> > >>>> I am unable to reproduce this behavior on my local tool shed > >>>> installation, which revision are you running? > >>>> > >>>> --Dave B. > >>>> > >>>> On 09/04/2013 06:57 AM, Greg Von Kuster wrote: > >>>>> Hello Simin, > >>>>> > >>>>> Bjoern is correct - if this is possible (which it looks like it is > >>>>> from > >>>> your traceback), then a bug has been introduced somewhat recently. > >>>> We'll take a look at this today and get a fix committed. Thanks > >>>> for reporting this. > >>>>> > >>>>> Greg Von Kuster > >>>>> > >>>>> On Sep 4, 2013, at 3:17 AM, Bjoern Gruening > >>>>> <bjoern.gruening(a)gmail.com> > >>>> wrote: > >>>>> > >>>>>> Hi Simon, > >>>>>> > >>>>>> you are right. Public usernames, or usernames associated with a > >>>>>> repository can't be changed. If you can that is a bug, please > >>>>>> fill a trello card with it. The reason is to guarantee > reproducibility. > >>>>>> If anyone has installed your repository the triple > >>>>>> (username,revision,toolshed) is saved to reinstall that > >>>>>> repository at any time, if needed. > >>>>>> > >>>>>> Cheers, > >>>>>> Bjoern > >>>>>> > >>>>>>>> It looks like it's trying to use the public name in the repo > >>>>>>>> path, which isn't going to work very well if public names can > >>>>>>>> be > >> changed. > >>>>>>>> > >>>>>>>> Changing my public name back to what it was before made it > >>>>>>>> start working again. > >>>>>>> > >>>>>>> To reply to my own post, I see now that when you create a user, > >>>>>>> a > >>>> comment on that page says: "You cannot change your public name > >>>> after you have created a repository in this tool shed." > >>>>>>> > >>>>>>> Does this mean: "If you change your public name after you have > >>>>>>> created a repository in this tool shed, those repositories won't > >>>>>>> work any more" or some such ;-). Or is there actually some > >>>>>>> code to stop the user changing their public name in this case, > >>>>>>> which would imply my toolshed is somehow broken in a way unique to > me? > >>>>>>> (I'm currently struggling to push tools into my toolshed using > >>>>>>> mercurial command line, through my apache front end, with the > >>>>>>> various layers of authentication, without it saying abort: > >>>>>>> authorization failed.) > >>>>>>> > >>>>>>> cheers, > >>>>>>> Simon > >>>>>>> > >>>>>>> > >>>>>>> ================================================================ > >>>>>>> == > >>>>>>> == > >>>>>>> === > >>>>>>> Attention: The information contained in this message and/or > >>>>>>> attachments from AgResearch Limited is intended only for the > >>>>>>> persons or entities to which it is addressed and may contain > >>>>>>> confidential and/or privileged material. Any review, > >>>>>>> retransmission, dissemination or other use of, or taking of any > >>>>>>> action in reliance upon, this information by persons or entities > >>>>>>> other than the intended recipients is prohibited by AgResearch > >>>>>>> Limited. If you have received this message in error, please > >>>>>>> notify > >> the sender immediately. > >>>>>>> ================================================================ > >>>>>>> == > >>>>>>> == > >>>>>>> === > >>>>>>> > >>>>>>> ___________________________________________________________ > >>>>>>> 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/ > >>>>> > >>>>> > >>>>> ___________________________________________________________ > >>>>> 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/ > >>>>> > >>> > >>> ==================================================================== > >>> == > >>> = > >>> Attention: The information contained in this message and/or > >>> attachments from AgResearch Limited is intended only for the persons > >>> or entities to which it is addressed and may contain confidential > >>> and/or privileged material. Any review, retransmission, > >>> dissemination or other use of, or taking of any action in reliance > >>> upon, this information by persons or entities other than the > >>> intended recipients is prohibited by AgResearch Limited. If you have > >>> received this message in error, please notify the sender immediately. > >>> ==================================================================== > >>> == > >>> = > >>> > >>> ___________________________________________________________ > >>> 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/ > > > > > > ====================================================================== > > = > > Attention: The information contained in this message and/or > > attachments from AgResearch Limited is intended only for the persons > > or entities to which it is addressed and may contain confidential > > and/or privileged material. Any review, retransmission, dissemination > > or other use of, or taking of any action in reliance upon, this > > information by persons or entities other than the intended recipients > > is prohibited by AgResearch Limited. If you have received this message > > in error, please notify the sender immediately. > > ====================================================================== > > = > > > > ___________________________________________________________ > > 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/ ======================================================================= Attention: The information contained in this message and/or attachments from AgResearch Limited is intended only for the persons or entities to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipients is prohibited by AgResearch Limited. If you have received this message in error, please notify the sender immediately. =======================================================================

2 1