Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nikolay Vazov
    @vazovn
    And these options must be generated on the fly in every tool menu
    M Bernt
    @bernt-matthias
    does the user -> account mapping change that often?
    Nikolay Vazov
    @vazovn
    Well, not that often indeed
    M Bernt
    @bernt-matthias
    Then I suggest to use a data table that you fill and update with a cron job.
    Nikolay Vazov
    @vazovn
    This is not a problem, I have a way of collecting the mapping any time. The problem is how to display this info in the <options>
    M Bernt
    @bernt-matthias
    Hmm.. but how to get the user info in the param filter .. ? Not sure.
    Nikolay Vazov
    @vazovn
    I used to do this in v17.05 by tweaking a function in basic.pywhich would insert into dynamic_parameters the account names as <options>.
    On the fly
    Ugly but working
            ## Nikolay - USIT
            ## Dynamically update the projects in the project job parameter dropdown
            elif self.__dict__['name'] == 'project':
               import Accounting_project_management
               user_static_options = Accounting_project_management.project_dropdown_update ( trans.user.email, self.static_options )
               return user_static_options
            else:
                return self.static_options
    where Accounting_project_management was my script.
    Don't think it is doable any more :)
    I will have to go out for 30 min. I'll join after that
    M Bernt
    @bernt-matthias

    So. Codefiles may be on options, but the question is if you can specify the code block in the job_resource_params_conf?

    For a data table approach you may have two selects: 1 for the user and the other for the project. But I guess you would like to have only the later select. The question is if its possible to access something like $__user_id__ in the tool form (e.g. fill a value of a hidden input or set an attribute of a filter)?

    Unfortunately I do not have an answer to both questions :(

    Nikolay Vazov
    @vazovn
    Thank you, Nicola. Well, Matthias, it is still unclear to me : are you going to modify the tool wrapper or job_resource_params_conf.xml in order to use the data table approach.
    4 replies
    selten
    @selten
    @mvdbeek sorry for mentioning you directly, but I thought you'd be quite interested in: galaxyproject/galaxy#10816
    Nicola Soranzo
    @nsoranzo
    @mvdbeek @jmchilton I find the separation of ContainerFinder and ContainerRegistry classes in lib/galaxy/tool_util/deps/containers.py confusing, any reason I should not try to merge the latter into the former?
    Martin Cech
    @martenson
    Galaxy requires boto3 and botocore packages, but seems to never use it, am I missing it somewhere?
    Nicola Soranzo
    @nsoranzo
    These are dependencies of other packages we require, since they are not listed in lib/galaxy/dependencies/pipfiles/default/Pipfile .
    Marius van den Beek
    @mvdbeek
    thanks @selten I am working on that
    Martin Cech
    @martenson
    @nsoranzo That surprises me.
    Marius van den Beek
    @mvdbeek
    @nsoranzo they are in tool-util, which may have seen external usage
    so if we’re refactoring those we should ideally not break anything
    @martenson they are dependencies of python-social-auth
    Martin Cech
    @martenson
    I am looking at possible s3 objectstore slowdown and found that what Galaxy uses - boto - might not officialy support py3
    Marius van den Beek
    @mvdbeek
    Anything specific ? The S3 interface does lots of ~wrong~ suboptimal things
    Martin Cech
    @martenson
    Not yet, copying from object store cache just feels slow. 17MBs.
    Simple test does 140+
    So I’m poking around a bit
    Marius van den Beek
    @mvdbeek
    did you install axel ? seems like that was meant for accelerating things
    Martin Cech
    @martenson
    never heard of it, do you have link or sth?
    that’s all I know
    Martin Cech
    @martenson
    hrmpf
    Nicola Soranzo
    @nsoranzo
    @mvdbeek Shouldn't be too difficult to keep compatibility
    John Chilton
    @jmchilton
    I'm biased obviously - but ContainerFinder introduces all sorts of Galaxy specific junk that it seems things should be useful without. There is a ton of Galaxy job specific and even Galaxy job config specific logic in there that should be decoupled from simply finding the container for a set of requirements
    M Bernt
    @bernt-matthias
    Is it expected that a tool with a non-optional select parameter can be submitted even if no value has been selected?
    Marius van den Beek
    @mvdbeek
    Yes, first value in the select is the default
    M Bernt
    @bernt-matthias
    This does not happen in this case: is <options from_data_table="..." /> and multiple="true".
    Marius van den Beek
    @mvdbeek
    # Multiple selects are optional by default, single selection is the inverse.
    M Bernt
    @bernt-matthias
    OK. Then we need to add a validator.
    Marius van den Beek
    @mvdbeek
    why not add optional="false” ?
    M Bernt
    @bernt-matthias
    even better :)
    Marius van den Beek
    @mvdbeek
    Looking at the code I think this should work, but if not I see no reason that we shouldn’t fix this
    Also seems like we should document that in the xsd
    M Bernt
    @bernt-matthias
    Will try with optional="false"
    Nolan Woods
    @innovate-invent
    @mvdbeek if the goal is just testing that patch I can do that in a dev instance and leave production until the next release
    I just wanted to make sure that it wasn't supposed to be a permanent patch for production