Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Helena
    @hexylena:matrix.org
    [m]
    I'm guessing this doesn't show in the UI either?
    Marius
    @mvdbeek:matrix.org
    [m]
    It should, let me see
    Helena
    @hexylena:matrix.org
    [m]
    also: I assume the interface is fine with only the orcid and no name? If so I think I'll start doing that (given my experiences rewriting tools that included old names.)
    1 reply
    neat!
    that is fantastic news, thank you!
    Helena
    @hexylena:matrix.org
    [m]
    ah and a name option so it's not just given/family, excellent work
    elichad: some good news! ^ there is a better way
    elichad
    @elichad:matrix.org
    [m]
    Perfect, thank you!
    gallardoalba
    @gallardoalba:matrix.org
    [m]
    Some stats which could be useful for identifying tools that could require to be reviewed (e.g. improve documentation)
    tcollins2011
    @tcollins2011:matrix.org
    [m]
    Alex and I were just talking and we were a little unclear on who to add in the author section in tools. Are we trying to just add PI's and the main creators or include people who helped develop the tool but aren't prominently named like originally discussed?
    1 reply
    Delphine Lariviere
    @delphine-l:matrix.org
    [m]
    To do for VGP : tool "Export Dataset" https://usegalaxy.eu/root?tool_id=export_remote : Need the option "Dataset Collection specifying their name"
    elichad
    @elichad:matrix.org
    [m]

    Getting some errors with planemo shed_lint when checking certain URLs, both in CI and local testing. Example:

    Applying linter tool_urls... FAIL
    .. ERROR: Error '503 Server Error: Service Temporarily Unavailable for url: https://pubs.acs.org/doi/10.1021/ct300849w' accessing https://doi.org/10.1021/ct300849w

    When I click through the links work fine (both the full link and the DOI link). Not all the URLs raise errors. Anyone know what's happening here?
    The CI run in question is: https://github.com/muon-spectroscopy-computational-project/muon-galaxy-tools/runs/6485736643?check_suite_focus=true

    Helena
    @hexylena:matrix.org
    [m]
    elichad
    @elichad:matrix.org
    [m]
    Tool tests: I see compare="sim_size" is now discouraged in favour of assert_contents -> has_size. Assuming I switch, if I am comparing a file that should be of a known size, but different contents, it fails the default compare="diff" check (which I don't want to run at all) before the has_size check. I guess I can change the compare type/parameters to something meaningless but passing, but wanted to flag as this doesn't feel like the way it should be
    bgruening
    @bgruening:matrix.org
    [m]
    elichad: if you compare content remove the "file" attribute
    It's not needed then
    elichad
    @elichad:matrix.org
    [m]
    Ah, of course, thanks
    Cristóbal Gallardo
    @gallardoalba:matrix.org
    [m]
    Hi all! Is it https://depot.galaxyproject.org/software/ still active? I realised that many packages haven't been updated for a while
    bgruening
    @bgruening:matrix.org
    [m]
    this repo is a storage for packages where we do not trust the source
    its not updated automatically, its meant to be a one-off storage
    if we do not use it, it could mean we do not need to mirror sources that often anymore
    Cristóbal Gallardo
    @gallardoalba:matrix.org
    [m]
    Mmmm but some bioconda-recipes include this repo as source, despite the updated packages are not hosted there (e.g. https://github.com/bioconda/bioconda-recipes/blob/master/recipes/bioconductor-org.dm.eg.db/meta.yaml#L12) Is it not a problem?
    Cristóbal Gallardo
    @gallardoalba:matrix.org
    [m]
    bgruening
    @bgruening:matrix.org
    [m]
    we have a migration running for that problem, curl does not follow symblinks in this case
    but you are correct, it seems bioconda is not moving the packages to the depot
    that should be our fallback
    elichad
    @elichad:matrix.org
    [m]
    On licences for tools - if we're wrapping a single package, should we be copying the license of that package for the tool wrapper? Or is the tool wrapper licence completely independent of the dependency and we can choose something more/less restrictive for the tool licence if we prefer?
    Similar question for workflows and tools with multiple dependencies
    bgruening
    @bgruening:matrix.org
    [m]
    The tool wrapper can be licenced differently
    Please less restrictive ;-)
    Tool descriptions and workflows can be licenced differently
    But keep in mind that the most restrictive license wins
    It's a race to the bottom:-(
    Wendi Bacon
    @nomadscientist
    Hi folks! We’re having a meeting about wrapping tools for single cell analysis this Thursday at 3PM-London time. Direct message me if you’d like to join and are up for wrapping some tools! :)
    Wendi Bacon
    @nomadscientist
    I want to put future such meetings on the Galaxy Events googlecalendar - how can I do that please?
    bgruening
    @bgruening:matrix.org
    [m]
    @nomadscientist: I think its the otherway around, you can add it to https://github.com/galaxyproject/galaxy-hub/tree/master/content/events
    and I think, or we should do that, publish from there into the calendar
    Cristóbal Gallardo
    @gallardoalba:matrix.org
    [m]
    Hi all! I'm getting this error when trying to run docker-based tools in my local instance: /tmp/tmp5m658hpi/job_working_directory/000/2/tool_script.sh: line 9: run_deepvariant: command not found Any idea about what could be the problem?
    Marius
    @mvdbeek:matrix.org
    [m]
    What do you mean by docker based tools ? Is that planemo ? Which tool? Did you use --biocontainers ?
    Cristóbal Gallardo
    @gallardoalba:matrix.org
    [m]
    Sorry, I wasn't clear enough; when running planemo s --galaxy_root ../xx/xx in tools that use docker it shows that error; also when using --biocontainers; however it works fine when using planemo test
    elichad
    @elichad:matrix.org
    [m]
    Just came across this old issue about citations galaxyproject/galaxy#5165 - any more recent plans to implement/support DOIs for tools, or include a pre-formatted citation for the tool itself in the citations section?
    e.g. a user might copy the citations from a tool or a history, but if they want to cite a tool wrapper itself, they'd have to write that citation manually
    elichad
    @elichad:matrix.org
    [m]
    in our specific case we could add a citation for our tools repo on github and that'd work ok, but it wouldn't work as well for something like tools-iuc where you have many unrelated tools by many authors
    Nicola Soranzo
    @nsoranzo:matrix.org
    [m]
    elichad: For tools installed from the ToolShed, I think it would be easy to automatically add a citation for the (versioned) ToolShed repo, e.g. https://toolshed.g2.bx.psu.edu/view/devteam/bowtie2/f6877ad76b00
    Nicola Soranzo
    @nsoranzo:matrix.org
    [m]
    You may want to open an issue for that, I don't think that galaxyproject/galaxy#5165 captures what you are after.
    Jennifer Hillman-Jackson
    @jennaj:matrix.org
    [m]
    Hi all -- would anyone have time to work on this? galaxyproject/tools-iuc#3850. Can follow up in the issue ticket. Bumping since came up in a Ghelp topic.