The last two galaxy-dist releases came mere hours after we updated our staging instance from our development instance, so I thought this time I'd actually ask. If we do an update today or tomorrow are we going to be instantly out of date again? :)
Thanks,
The last two galaxy-dist releases came mere hours after we updated our staging instance from our development instance, so I thought this time I'd actually ask. If we do an update today or tomorrow are we going to be instantly out of date again? :)
Surprisingly, yes, we are planning a galaxy-dist release in the next couple days or, at latest, early next week.
J.
On Wed, Nov 17, 2010 at 02:21:39PM -0500, Jeremy Goecks wrote:
The last two galaxy-dist releases came mere hours after we updated our staging instance from our development instance, so I thought this time I'd actually ask. If we do an update today or tomorrow are we going to be instantly out of date again? :)
Surprisingly, yes, we are planning a galaxy-dist release in the next couple days or, at latest, early next week.
Heh, Thanks, Jeremy. I'll see if I can hold the line here until it drops. Hugely appreciate galaxy and the tip.
Hi all!
Out of curiosity, is there some kind of versioning in Galaxy (e.g. for the stable release intended for end-users)?
Something that would allow us to say things like: 'The tool works fine for versions 1.2 and above.', etc.
Cheers, Kostas
On 17 November 2010 20:24, Ry4an Brase <ry4an+galaxy@msi.umn.edury4an%2Bgalaxy@msi.umn.edu
wrote:
On Wed, Nov 17, 2010 at 02:21:39PM -0500, Jeremy Goecks wrote:
The last two galaxy-dist releases came mere hours after we updated our staging instance from our development instance, so I thought this time I'd actually ask. If we do an update today or tomorrow are we going to be instantly out of date again? :)
Surprisingly, yes, we are planning a galaxy-dist release in the next couple days or, at latest, early next week.
Heh, Thanks, Jeremy. I'll see if I can hold the line here until it drops. Hugely appreciate galaxy and the tip.
-- Ry4an Brase 612-626-6575 Software Developer Application Development University of Minnesota Supercomputing Institute http://www.msi.umn.edu _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
On Thu, Nov 18, 2010 at 10:06 AM, Kostas Karasavvas kostas.karasavvas@nbic.nl wrote:
Hi all!
Out of curiosity, is there some kind of versioning in Galaxy (e.g. for the stable release intended for end-users)?
Something that would allow us to say things like: 'The tool works fine for versions 1.2 and above.', etc.
Cheers, Kostas
I'd also welcome official version numbers for Galaxy. It would also make it easier for citation purposes (e.g. Galaxy workflow available in online supplementary materials, tested with Galaxy version x,y,z).
I'd also like to ask a technical question about the galaxy-dist and galaxy-central repositories: Is the default branch on galaxy-dist identical to (but of course usually older than) the default branch on galaxy-central?
[I'm thinking about the occasional need to update a production server originally cloned from galaxy-dist to get a fix from galaxy-central before you guys make it available on galaxy-dist]
Thanks,
Peter
Peter wrote:
On Thu, Nov 18, 2010 at 10:06 AM, Kostas Karasavvas kostas.karasavvas@nbic.nl wrote:
Hi all!
Out of curiosity, is there some kind of versioning in Galaxy (e.g. for the stable release intended for end-users)?
Something that would allow us to say things like: 'The tool works fine for versions 1.2 and above.', etc.
Cheers, Kostas
I'd also welcome official version numbers for Galaxy. It would also make it easier for citation purposes (e.g. Galaxy workflow available in online supplementary materials, tested with Galaxy version x,y,z).
These already exist as the numerical and unique changeset IDs, they just don't take the traditional X.Y.Z form.
I'd also like to ask a technical question about the galaxy-dist and galaxy-central repositories: Is the default branch on galaxy-dist identical to (but of course usually older than) the default branch on galaxy-central?
Correct.
[I'm thinking about the occasional need to update a production server originally cloned from galaxy-dist to get a fix from galaxy-central before you guys make it available on galaxy-dist]
This should always be fine from a Mercurial point of view.
--nate
Thanks,
Peter
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
Victor,
The form definitions can be modified by an admin in Manage Forms in the admin view. Click on 'Edit' popup menu next to any form name to modify form name, description or its fields.
Thanks rc
On Nov 22, 2010, at 1:59 PM, Victor Ruotti wrote:
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Victor and rc; Victor, the nglims extension on top of rc's work compartmentalizes the form generation into the YAML configuration in tool-data/nglims.yaml. The setup script (scripts/nglims/add_ng_defaults.py) uses this to fill in the form information programatically, and then the controller uses this to sort out naming in managing the samples.
This all uses rc's form infrastructure, so the editing with Manage Forms will work fine.
This is probably not as generalized as it could be so there will be some hidden naming dependencies depending on what you're planning to do. Let me know if you run into issues with that aspect,
Brad
Victor,
The form definitions can be modified by an admin in Manage Forms in the admin view. Click on 'Edit' popup menu next to any form name to modify form name, description or its fields.
Thanks rc
On Nov 22, 2010, at 1:59 PM, Victor Ruotti wrote:
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Thank you Brad for your response. We now have a the nglims system in place. We can allow the submission of samples via the Lab tab. Also, the project shows up in the tracking request form via the admin tab.
I do have a question that is the only thing stopping us from fully implementing nglims. How do we associate a data library to samples. We tried creating a data library for storing all of our runs and having a hard time associating a data library with a sample. Attached is a snapshot of the page. We tried setting the permissions and still cant see the data libraries under the sample. Any ideas?
Thanks again for all you help. Very impressed with all as always. Victor
On Nov 22, 2010, at 3:11 PM, Brad Chapman wrote:
Victor and rc; Victor, the nglims extension on top of rc's work compartmentalizes the form generation into the YAML configuration in tool-data/nglims.yaml. The setup script (scripts/nglims/add_ng_defaults.py) uses this to fill in the form information programatically, and then the controller uses this to sort out naming in managing the samples.
This all uses rc's form infrastructure, so the editing with Manage Forms will work fine.
This is probably not as generalized as it could be so there will be some hidden naming dependencies depending on what you're planning to do. Let me know if you run into issues with that aspect,
Brad
Victor,
The form definitions can be modified by an admin in Manage Forms in the admin view. Click on 'Edit' popup menu next to any form name to modify form name, description or its fields.
Thanks rc
On Nov 22, 2010, at 1:59 PM, Victor Ruotti wrote:
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
Victor,
The data library select field lists all publicly available data libraries and the one's the sequencing request owner can access. So, if you create a data library which is public to all Galaxy users or is accessible to the user who owns the sequencing request, then that data library should show up in the select field against the sample.
We are working on adding a 'create new data library' feature on the edit samples page, which would be available in the near future.
rc
On Nov 24, 2010, at 3:49 PM, Victor Ruotti wrote:
Thank you Brad for your response. We now have a the nglims system in place. We can allow the submission of samples via the Lab tab. Also, the project shows up in the tracking request form via the admin tab.
I do have a question that is the only thing stopping us from fully implementing nglims. How do we associate a data library to samples. We tried creating a data library for storing all of our runs and having a hard time associating a data library with a sample. Attached is a snapshot of the page. We tried setting the permissions and still cant see the data libraries under the sample. Any ideas?
Thanks again for all you help. Very impressed with all as always. Victor
On Nov 22, 2010, at 3:11 PM, Brad Chapman wrote:
Victor and rc; Victor, the nglims extension on top of rc's work compartmentalizes the form generation into the YAML configuration in tool-data/nglims.yaml. The setup script (scripts/nglims/ add_ng_defaults.py) uses this to fill in the form information programatically, and then the controller uses this to sort out naming in managing the samples.
This all uses rc's form infrastructure, so the editing with Manage Forms will work fine.
This is probably not as generalized as it could be so there will be some hidden naming dependencies depending on what you're planning to do. Let me know if you run into issues with that aspect,
Brad
Victor,
The form definitions can be modified by an admin in Manage Forms in the admin view. Click on 'Edit' popup menu next to any form name to modify form name, description or its fields.
Thanks rc
On Nov 22, 2010, at 1:59 PM, Victor Ruotti wrote:
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
<Screen shot 2010-11-24 at 2.48.03 PM.png> <Screen shot 2010-11-24 at 2.48.49 PM.png>
Thank you RC. I now have a data library and a folder within the data library associated to a sample which was submitted by using the Lab tab (part of nglims). Attached is a snapshot of a sample that I created via the lab tab. Say as an admin I now create a sequencing request. How do I choose the samples submitted by the Lab tab? I see I can specify a sample name. But, I think we want/need to add the samples that were already set by the Lab tab. Sorry if I'm not understanding the workflow. I think it would be great if Researchers can submit samples as listed in the Lab tab section. Then the sequencing team can create a run with those samples that . In our case 7 or 8 samples per flowcell (illumina GAII). That way al the meta data from those samples that were entered via the Lab tab can be tracked by the researchers and the sequencing team. Does that make sense?
Thank you. Victor
On Nov 24, 2010, at 3:02 PM, Ramkrishna Chakrabarty wrote:
Victor,
The data library select field lists all publicly available data libraries and the one's the sequencing request owner can access. So, if you create a data library which is public to all Galaxy users or is accessible to the user who owns the sequencing request, then that data library should show up in the select field against the sample.
We are working on adding a 'create new data library' feature on the edit samples page, which would be available in the near future.
rc
On Nov 24, 2010, at 3:49 PM, Victor Ruotti wrote:
Thank you Brad for your response. We now have a the nglims system in place. We can allow the submission of samples via the Lab tab. Also, the project shows up in the tracking request form via the admin tab.
I do have a question that is the only thing stopping us from fully implementing nglims. How do we associate a data library to samples. We tried creating a data library for storing all of our runs and having a hard time associating a data library with a sample. Attached is a snapshot of the page. We tried setting the permissions and still cant see the data libraries under the sample. Any ideas?
Thanks again for all you help. Very impressed with all as always. Victor
On Nov 22, 2010, at 3:11 PM, Brad Chapman wrote:
Victor and rc; Victor, the nglims extension on top of rc's work compartmentalizes the form generation into the YAML configuration in tool-data/nglims.yaml. The setup script (scripts/nglims/add_ng_defaults.py) uses this to fill in the form information programatically, and then the controller uses this to sort out naming in managing the samples.
This all uses rc's form infrastructure, so the editing with Manage Forms will work fine.
This is probably not as generalized as it could be so there will be some hidden naming dependencies depending on what you're planning to do. Let me know if you run into issues with that aspect,
Brad
Victor,
The form definitions can be modified by an admin in Manage Forms in the admin view. Click on 'Edit' popup menu next to any form name to modify form name, description or its fields.
Thanks rc
On Nov 22, 2010, at 1:59 PM, Victor Ruotti wrote:
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
<Screen shot 2010-11-24 at 2.48.03 PM.png> <Screen shot 2010-11-24 at 2.48.49 PM.png>
Victor,
Galaxy has two separate sample tracking systems, a native system as described in the Help menu item in the Lab menu and one developed by Brad Chapman called NGLIMS. In Galaxy's native sample tracking system, a user creates a sequencing request using the Lab tab and submits it. Then the lab manger receives the same sequencing request in the admin tab and assigns barcodes, changes sample states and transfers datasets and so on. However, in Brad's NGLIMS I believe the workflow is different. I do not think you can create samples using Brad's NGLIMS and track and manage the samples in the admin tab using the native sample tracking system.
regards rc
On Nov 25, 2010, at 7:04 PM, Victor Ruotti wrote:
Thank you RC. I now have a data library and a folder within the data library associated to a sample which was submitted by using the Lab tab (part of nglims). Attached is a snapshot of a sample that I created via the lab tab. Say as an admin I now create a sequencing request. How do I choose the samples submitted by the Lab tab? I see I can specify a sample name. But, I think we want/need to add the samples that were already set by the Lab tab. Sorry if I'm not understanding the workflow. I think it would be great if Researchers can submit samples as listed in the Lab tab section. Then the sequencing team can create a run with those samples that . In our case 7 or 8 samples per flowcell (illumina GAII). That way al the meta data from those samples that were entered via the Lab tab can be tracked by the researchers and the sequencing team. Does that make sense?
Thank you. Victor
On Nov 24, 2010, at 3:02 PM, Ramkrishna Chakrabarty wrote:
Victor,
The data library select field lists all publicly available data libraries and the one's the sequencing request owner can access. So, if you create a data library which is public to all Galaxy users or is accessible to the user who owns the sequencing request, then that data library should show up in the select field against the sample.
We are working on adding a 'create new data library' feature on the edit samples page, which would be available in the near future.
rc
On Nov 24, 2010, at 3:49 PM, Victor Ruotti wrote:
Thank you Brad for your response. We now have a the nglims system in place. We can allow the submission of samples via the Lab tab. Also, the project shows up in the tracking request form via the admin tab.
I do have a question that is the only thing stopping us from fully implementing nglims. How do we associate a data library to samples. We tried creating a data library for storing all of our runs and having a hard time associating a data library with a sample. Attached is a snapshot of the page. We tried setting the permissions and still cant see the data libraries under the sample. Any ideas?
Thanks again for all you help. Very impressed with all as always. Victor
On Nov 22, 2010, at 3:11 PM, Brad Chapman wrote:
Victor and rc; Victor, the nglims extension on top of rc's work compartmentalizes the form generation into the YAML configuration in tool-data/nglims.yaml. The setup script (scripts/nglims/ add_ng_defaults.py) uses this to fill in the form information programatically, and then the controller uses this to sort out naming in managing the samples.
This all uses rc's form infrastructure, so the editing with Manage Forms will work fine.
This is probably not as generalized as it could be so there will be some hidden naming dependencies depending on what you're planning to do. Let me know if you run into issues with that aspect,
Brad
Victor,
The form definitions can be modified by an admin in Manage Forms in the admin view. Click on 'Edit' popup menu next to any form name to modify form name, description or its fields.
Thanks rc
On Nov 22, 2010, at 1:59 PM, Victor Ruotti wrote:
Hi, We have a question about NGLIMS. How do we go and where do we go to change things. For example the default sample submission forms etc. Thanks in advance. Victor
galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
<Screen shot 2010-11-24 at 2.48.03 PM.png> <Screen shot 2010-11-24 at 2.48.49 PM.png>
<Screen shot 2010-11-25 at 5.18.31 PM.png><Screen shot 2010-11-25 at 5.17.39 PM.png>
Victor;
Thank you RC. I now have a data library and a folder within the data library associated to a sample which was submitted by using the Lab tab (part of nglims).
Attached is a snapshot of a sample that I created via the lab tab. Say as an admin I now create a sequencing request. How do I choose the samples submitted by the Lab tab?
You probably don't want to mix the "nglims" approach with Galaxy's native sample tracking functionality. While I've build the nglims part to use the same database tables and be fairly interoperable, it does take some different data representation choices, especially with regards to the sample/request relationship.
Apologies if this is confusing; I can answer below from the nglims approach here, and rc can hopefully provide more background from the native Galaxy sample tracking approach.
I see I can specify a sample name. But, I think we want/need to add the samples that were already set by the Lab tab. Sorry if I'm not understanding the workflow. I think it would be great if Researchers can submit samples as listed in the Lab tab section. Then the sequencing team can create a run with those samples that . In our case 7 or 8 samples per flowcell (illumina GAII). That way al the meta data from those samples that were entered via the Lab tab can be tracked by the researchers and the sequencing team. Does that make sense?
In nglims, you want to associate a user in the sequencing team with the"sequencing" role using the standard Admin tools to manage roles.
This user will then have additional menu options in the left panel when you go to Lab->Next gen sample submission. Specifically, the Queues link allows these users to manage samples as they come in. They move the samples through various steps in tandem with things happening in the lab:
Awaiting Sample -> Pre-sequencing quantitation -> Sequencing
Once they are in the sequencing step, you can prepare a flowcell and associate samples with lanes using a drag and drop interface.
So in this view, the queues manage various samples as they come in and then the 'Prepare flow cell' step associates them with a sequencing run.
Hope this helps, Brad
On Mon, Nov 22, 2010 at 6:44 PM, Nate Coraor nate@bx.psu.edu wrote:
I'd also welcome official version numbers for Galaxy. It would also make it easier for citation purposes (e.g. Galaxy workflow available in online supplementary materials, tested with Galaxy version x,y,z).
These already exist as the numerical and unique changeset IDs, they just don't take the traditional X.Y.Z form.
Quite - and they are much less useful as a result.
Hg changeset IDs (and likewise git hashes) are numerical (if you understand hex) and unique, but one important drawback is they are not strictly increasing. You can't take two changeset IDs and know which is older and which is newer.
Changeset IDs are also not PEP 386 compliant version numbers ;) http://www.python.org/dev/peps/pep-0386/
In a method section of a paper I really don't want to write "We used Galaxy changeset 8729d2e29b02", I'd rather say "We used the Galaxy distribution release of 17 Nov 2010" (that date may be wrong, bitbucket says "5 days ago" rather than a real date), but it would be nicer and more normal to just say "We used Galaxy release 1.2.3" (or whatever).
I also very much agree with the point Kostas made about writing tools and wanting to say "This works on Galaxy version 1.2.3 or later". Here again I'd opt for the date as a human friendly substitute since the changeset ID is quite inappropriate in my opinion.
Yes, I recognise this is a partly a social rather than technical issue, and isn't going to stop me using or recommending Galaxy, but I think this needs to be voiced.
For people using the Penn State Galaxy instance this is largely irrelevant, but for local Galaxy installs (and there may be more than one per institute) having an easy way to check their version number would be very useful (I think it should be included in the footer of the welcome page or something by default). Even for simple things like cross checking bugs, a simple Galaxy version number would be useful.
Finally, If you hope to get Galaxy provided as a package by Linux distributions on day (which might be a nice idea if development ever slows down), then they also prefer "tradition" version schemes.
I've probably gone on enough now ;)
What do other people think?
I'd also like to ask a technical question about the galaxy-dist and galaxy-central repositories: Is the default branch on galaxy-dist identical to (but of course usually older than) the default branch on galaxy-central?
Correct.
Thank you.
[I'm thinking about the occasional need to update a production server originally cloned from galaxy-dist to get a fix from galaxy-central before you guys make it available on galaxy-dist]
This should always be fine from a Mercurial point of view.
Great.
Thanks for the clarification wrt the branch situation.
Peter
Peter, I largely agree on the versioning being more clear.... For peer reviewed papers though I tend to refer to the exact data analysis hosted/present on our local galaxy instance (which will hopefully outside intranet reachable as well. That I underline of the galaxy team would be the most ultimate reference of a data analysis set in my opinion. But anyway, we haven't been in that position (yet).
Cheers Alex
-----Oorspronkelijk bericht----- Van: galaxy-dev-bounces@lists.bx.psu.edu [mailto:galaxy-dev-bounces@lists.bx.psu.edu] Namens Peter Verzonden: maandag 22 november 2010 21:46 Aan: Nate Coraor CC: Galaxy Dev Onderwerp: Re: [galaxy-dev] Is there a galaxy-dist release coming soon?
On Mon, Nov 22, 2010 at 6:44 PM, Nate Coraor nate@bx.psu.edu wrote:
I'd also welcome official version numbers for Galaxy. It would also make it easier for citation purposes (e.g. Galaxy workflow available in online supplementary materials, tested with Galaxy version x,y,z).
These already exist as the numerical and unique changeset IDs, they just don't take the traditional X.Y.Z form.
Quite - and they are much less useful as a result.
Hg changeset IDs (and likewise git hashes) are numerical (if you understand hex) and unique, but one important drawback is they are not strictly increasing. You can't take two changeset IDs and know which is older and which is newer.
Changeset IDs are also not PEP 386 compliant version numbers ;) http://www.python.org/dev/peps/pep-0386/
In a method section of a paper I really don't want to write "We used Galaxy changeset 8729d2e29b02", I'd rather say "We used the Galaxy distribution release of 17 Nov 2010" (that date may be wrong, bitbucket says "5 days ago" rather than a real date), but it would be nicer and more normal to just say "We used Galaxy release 1.2.3" (or whatever).
I also very much agree with the point Kostas made about writing tools and wanting to say "This works on Galaxy version 1.2.3 or later". Here again I'd opt for the date as a human friendly substitute since the changeset ID is quite inappropriate in my opinion.
Yes, I recognise this is a partly a social rather than technical issue, and isn't going to stop me using or recommending Galaxy, but I think this needs to be voiced.
For people using the Penn State Galaxy instance this is largely irrelevant, but for local Galaxy installs (and there may be more than one per institute) having an easy way to check their version number would be very useful (I think it should be included in the footer of the welcome page or something by default). Even for simple things like cross checking bugs, a simple Galaxy version number would be useful.
Finally, If you hope to get Galaxy provided as a package by Linux distributions on day (which might be a nice idea if development ever slows down), then they also prefer "tradition" version schemes.
I've probably gone on enough now ;)
What do other people think?
I'd also like to ask a technical question about the galaxy-dist and galaxy-central repositories: Is the default branch on galaxy-dist identical to (but of course usually older than) the default branch on galaxy-central?
Correct.
Thank you.
[I'm thinking about the occasional need to update a production server originally cloned from galaxy-dist to get a fix from galaxy-central before you guys make it available on galaxy-dist]
This should always be fine from a Mercurial point of view.
Great.
Thanks for the clarification wrt the branch situation.
Peter _______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev
galaxy-dev@lists.galaxyproject.org
-
Bossers, Alex -
Brad Chapman -
Jeremy Goecks -
Kostas Karasavvas -
Nate Coraor -
Peter -
Ramkrishna Chakrabarty -
Ry4an Brase -
Victor Ruotti