iracooke@gmail.com, bjoern.gruening@gmail.com, marc.vaudel@biomed.uib.no, harald.barsnes@gmail.com

179 views
Skip to first unread message

Candace Guerrero

unread,
Oct 20, 2014, 5:31:27 PM10/20/14
to Galaxy for Proteomics
Hello Everyone,

Let me introduce myself. I am Candace - a new post-doc in Tim's lab and I will be working on testing of PeptideShaker tool witin GalaxyP.

I would like to give a short update for the PeptideShaker tool in GalaxyP 2014 (the latest version of GalaxyP).  Currently, PeptideShaker can successfully use a single file or data set collection to generate all PeptideShaker output options. However, when trying to open the cps file in a desktop version of PeptideShaker it fails to open. We believe this is due to the inability for PeptideShaker to access other files needed and that would usually be stored in the same path. Because cps files are storing absolute paths, there is no way for the desktop viewer to access these files when using GalaxyP 2014. Is there a way to package all the needed files in to a large comprehensive Galaxy cps file so that a desktop version of Peptide Shaker could open it? 


Regards,


Candace

Gmail

unread,
Oct 20, 2014, 6:47:23 PM10/20/14
to Candace Guerrero, Galaxy for Proteomics
Hi Candace

It's great news that you are working on this!! I believe that recent versions of peptide shaker and searchgui have implemented a feature whereby all necessary files are packaged into a zip. I haven't explored this at all myself though so I can't say much about the details. 

Best wishes

Ira


Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "Galaxy for Proteomics" group.
To post to this group, send email to gal...@umn.edu.
Visit this group at http://groups.google.com/a/umn.edu/group/galaxyp/.
To view this discussion on the web visit https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAD0XxZxcMx1hprTvoxFvhwvk8UpB%3DS6dJDaXY2K%3DN1fTgEctMw%40mail.gmail.com.

To unsubscribe from this group and stop receiving emails from it, send an email to galaxyp+u...@umn.edu.

harald.barsnes

unread,
Oct 20, 2014, 7:23:24 PM10/20/14
to gal...@umn.edu, cgue...@umn.edu
 
Hi Candace,

Ira is perfectly correct. In recent versions of PeptideShaker (starting from version 0.32.0) it is now possible to get all the required files in a single zip file by adding "-zip path_to_zip_file" to the PeptideShaker command line.

The created zip file will contain the PeptideShaker cps file and a data folder with the required fasta and mgf files.

As to the references to absolute paths, PeptideShaker will also look for the files in the same folder as the cps file and in any folders called "data". Or the user can provide missing files manually.

Best regards,
Harald
(Sorry if this message appears more than once. I first tried to reply directly to the e-mail.)

Marc Vaudel

unread,
Oct 21, 2014, 5:04:39 AM10/21/14
to Gmail, Candace Guerrero, Galaxy for Proteomics
Hi Candace, hi everyone,

First of all, welcome in the team Candace! Ira is correct, we have been working on packaging the files needed for SearchGUI and PeptideShaker. The current online versions should circumvent this problem, make a clean history, smaller files, and a simpler workflow: one file in, one file out :)

In SearchGUI (cf "Optional output compression parameters" in https://code.google.com/p/searchgui/wiki/SearchCLI), you can select the following packaging options:
0: all export files compressed in a single zip file, nice for single shot analyses
1: one zip file per run (ie mgf file), nice when working with fractions
2: one zip file per algorithm, nice when benchmarking search engine efficiency
3: No zipping, would not recommend that in Galaxy as the history gets quite messy
That way the user can choose the organization of the output according to his project and will see it organized in the history accordingly. Note that the zip files names will all end by "searchgui_out.zip" for you to recognize them easily - we can make this a parameter. An additional command line parameter (-output_data) will allow you to include resource files in the packaged files, would recommend that by default in Galaxy. Then, these files are standalone results, you don't need to keep track of the mgf and fasta files, and can feed the zip files directly to follow-up tools.

You can thus provide the zip file to PeptideShaker and it will process it using the included mgf and fasta files. Similarly, if you want to package the PeptideShaker output in a standalone file, just use the -zip option (cf "Optional output parameters" in https://code.google.com/p/peptide-shaker/wiki/PeptideShakerCLI). Here again, you will have a single file in your history, and upon unzipping it will be readily loadable on your desktop computer :)

Hope this solves your problem. I think the most relevant bit for you ist that if you include the resource files in the output of the tools, you will not need to keep track of them between SearchGUI and PeptideShaker processes. That should allow you to make two independent wrappers, and run them independently. For example, you can run PeptideShaker on the same SearchGUI output - or just one search engine or fraction output - using different parameters (like different PTM localization scores) without having to rerun the search. The process would thus be much cleaner and the setup more flexible :) And if we can improve the way this is handled, we will be happy to help!

Best regards,

Marc







Marc Vaudel

unread,
Oct 21, 2014, 5:13:11 AM10/21/14
to harald.barsnes, Galaxy for Proteomics, Candace Guerrero
oops, sorry did not see that Harald already answered :)

Pratik Jagtap

unread,
Oct 23, 2014, 4:17:26 PM10/23/14
to Marc Vaudel, harald.barsnes, Galaxy for Proteomics, Candace Guerrero, Ira Cooke, Björn Grüning, Jim Johnson, Timothy Griffin
Hello Marc and Harald,

Great News !

While Candace is looking into 0.34 version outside of GalaxyP - we can discuss on plans to wrap the latest version of GalaxyP.

Harald and Marc - when do you anticipate 0.35 version to be available? Would it be worthwhile to wait for the new version and wrap for GalaxyP usage or do you think proceeding with 0.34 would be okay?

Ira and Bjoern - would you be able to wrap the latest version of  PeptideShaker (0.34 or 0.35 when it is available) - so that it can be uploaded onto the new GalaxyP instance?

Another decision we will have to make is on how frequently should PeptideShaker be Galaxy-wrapped? With frequent changes taking place we should make a decision on wrapping it once or twice a year. Any thoughts?

Looking forward to this project progressing further.

Regards,

Pratik

harald.barsnes

unread,
Oct 23, 2014, 4:57:43 PM10/23/14
to gal...@umn.edu, mva...@gmail.com, harald....@gmail.com, cgue...@umn.edu, irac...@gmail.com, bjoern....@gmail.com, j...@umn.edu, tgri...@umn.edu
 
Hi Pratik,
 
PeptideShaker v0.35.0 and SearchGUI v1.22.0 have just been released! So I'd recommend going with these latest versions. :)
 
Among the updates in the latest versions:
- Support for Comet (http://comet-ms.sourceforge.net). (Windows and Linux)
- Updated version of MS Amanda which now also is supported on Linux.*
- Complex PTM setups are now handled better.
- The processing of data in PeptideShaker is faster.
 
* At least in theory. It requires the installation of Mono (http://www.mono-project.com), and should be regarded as beta. But might be worth a shot, as the results from our testing so far look pretty good.
 
As to the question of how often to update the SearchGUI and PeptideShaker versions in Galaxy, I'd say that once or twice a year sounds very infrequent. As you can see from our release notes we release new versions of our tools almost every month. Granted some of these are just minor updates and not all versions have to be wrapped for Galaxy. But if we wait half a year between each update then the versions in Galaxy will become fairly outdated compared to the standalone versions.
 
However, updating to new versions of SearchGUI and PeptideShaker should usually not require any change to the command lines, and should in most cases be as easy as replacing the two jar files? So unless the rest of the job of wrapping SearchGUI and PeptideShaker is very time consuming I don't see why more frequent updates should be a problem?
 
Best regards,
Harald 

Ira Cooke

unread,
Oct 23, 2014, 5:50:31 PM10/23/14
to harald.barsnes, gal...@umn.edu, mva...@gmail.com, cgue...@umn.edu, bjoern....@gmail.com, j...@umn.edu, tgri...@umn.edu
Hi Harald, 

Thanks for this info.  I agree that it would be good to go for frequent updates (to avoid stagnation of the wrapper) … but the main issue is that with such frequent updates it’s often not feasible to thoroughly check the tool in between releases.  It’s quite easy for a small change in the CLI to break the wrapper.  Ideally we’d setup some automated testing for the wrapper .. (perhaps using planemo https://github.com/galaxyproject/planemo ) to ensure that our releases are not causing breakages.

I think Bjorn already has some experience with Planemo … what do you think about this Bjoern?  

Cheers
Ira

Marc Vaudel

unread,
Oct 24, 2014, 4:44:24 AM10/24/14
to Ira Cooke, harald.barsnes, Galaxy for Proteomics, Candace Guerrero, Björn Grüning, Jim Johnson, Timothy Griffin
Hi Ira,

I totally agree with Harald and you, it is better that the updates follow the development rather than wait six month to deploy an important bug fix. We generally have minor and major releases, involving bug fixes and algorithm development, respectively. Most of the former are not relevant for Galaxy since they often concern the gui usage. The latter should definitely be included so that the version in Galaxy is in line with the desktop version. Major releases are completed only few times a year since it takes several months to test everything, so that should be a good rhythm?

Of course, we will keep you posted when a new version is deployed and when it includes command line changes, as we do already. Having additional automated testing would definitely be a plus! Is there also a way for us to automatically send new versions to you guys upon release?

In all cases, we will be happy to help so that the update process goes smoothly :)

Marc

Björn Grüning

unread,
Oct 24, 2014, 7:23:11 AM10/24/14
to Marc Vaudel, Ira Cooke, harald.barsnes, Galaxy for Proteomics, Candace Guerrero, Jim Johnson, Timothy Griffin, pjagtap@umn.edu >> Pratik Jagtap
Hi all!

First of all. Great work guys! The new release seems to be amazing!

> I totally agree with Harald and you, it is better that the updates follow
> the development rather than wait six month to deploy an important bug fix.
> We generally have minor and major releases, involving bug fixes and
> algorithm development, respectively. Most of the former are not relevant
> for Galaxy since they often concern the gui usage. The latter should
> definitely be included so that the version in Galaxy is in line with the
> desktop version. Major releases are completed only few times a year since
> it takes several months to test everything, so that should be a good rhythm?

Yes, this seems to be good. Marc how do you test this. Are there some
test-data (small ones) that you regularly check?

> Of course, we will keep you posted when a new version is deployed and when
> it includes command line changes, as we do already. Having additional
> automated testing would definitely be a plus! Is there also a way for us to
> automatically send new versions to you guys upon release?

Do you mean the final tarball, but not released yet?
I would propose to finally agree on one repository for the wrappers and
everyone can create PR and you guys can fill trello issues if you like,
with the functionality etc. ... so we can work on this.

Otherwise, your update mails are really great. This works good. My main
concern right now is, that I don't know which wrapper version is the
most recent one.

@JJ, Ira, Pratik
Is this the most recent one:
https://bitbucket.org/BjoernGruening/peptideshaker

One which branch you are working currently? Where do you want to have
the master repository.

Q1:
- github
- bitbucket

Q2:
- IUC repository (https://github.com/galaxyproject/tools-iuc)
- GalaxyP repository
- new one?

The IUC will have the advantage that a few of us already have commit
access and this one will soon get an automatic test suite, based on
Travis and automated update to the test-toolshed (-14 days before a
Galaxy release) and automatic Tool Shed update for every Galaxy release.

> In all cases, we will be happy to help so that the update process goes
> smoothly :)

Very nice! Thanks a lot!
Bjoern

> Marc
>
> 2014-10-23 23:50 GMT+02:00 Ira Cooke <irac...@gmail.com>:
>
>> Hi Harald,
>>
>> Thanks for this info. I agree that it would be good to go for frequent
>> updates (to avoid stagnation of the wrapper) … but the main issue is that
>> with such frequent updates it’s often not feasible to thoroughly check the
>> tool in between releases. It’s quite easy for a small change in the CLI to
>> break the wrapper. Ideally we’d setup some automated testing for the
>> wrapper .. (perhaps using planemo https://github.com/galaxyproject/planemo )
>> to ensure that our releases are not causing breakages.
>>
>> I think Bjorn already has some experience with Planemo … what do you think
>> about this Bjoern?
>>
>> Cheers
>> Ira
>>
>>
>> On 24 Oct 2014, at 7:57 am, harald.barsnes <harald....@gmail.com>
>> wrote:
>>
>>
>> Hi Pratik,
>>
>> PeptideShaker v0.35.0 and SearchGUI v1.22.0 have just been released! So
>> I'd recommend going with these latest versions. :)
>>
>> Among the updates in the latest versions:
>> - Support for Comet (*http://comet-ms.sourceforge.net*
>> <http://comet-ms.sourceforge.net/>). (Windows and Linux)
>> - Updated version of MS Amanda which now also is supported on Linux.*
>> - Complex PTM setups are now handled better.
>> - The processing of data in PeptideShaker is faster.
>>
>> * At least in theory. It requires the installation of Mono (
>> *http://www.mono-project.com* <http://www.mono-project.com/>), and should
>>>>>> <https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAD0XxZxcMx1hprTvoxFvhwvk8UpB%3DS6dJDaXY2K%3DN1fTgEctMw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>>> an email to galaxyp+u...@umn.edu.
>>>>>>
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Galaxy for Proteomics" group.
>>>>> To post to this group, send email to gal...@umn.edu.
>>>>> Visit this group at http://groups.google.com/a/umn.edu/group/galaxyp/.
>>>>> To view this discussion on the web visit https://groups.google.com/a/
>>>>> umn.edu/d/msgid/galaxyp/e0595d17-a4f5-4f6b-b30e-132fa280460c%40umn.edu
>>>>> <https://groups.google.com/a/umn.edu/d/msgid/galaxyp/e0595d17-a4f5-4f6b-b30e-132fa280460c%40umn.edu?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to galaxyp+u...@umn.edu.
>>>>>
>>>>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Galaxy for Proteomics" group.
>>>> To post to this group, send email to gal...@umn.edu.
>>>> Visit this group at http://groups.google.com/a/umn.edu/group/galaxyp/.
>>>> To view this discussion on the web visit https://groups.google.com/a/
>>>> umn.edu/d/msgid/galaxyp/CAE1e1duUReRuAi%2BbjsTHNfTmb2fMsYCcyVK7mjg-
>>>> EGqrPEvcmg%40mail.gmail.com
>>>> <https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAE1e1duUReRuAi%2BbjsTHNfTmb2fMsYCcyVK7mjg-EGqrPEvcmg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
>>>
>>
>

Björn Grüning

unread,
Oct 24, 2014, 7:26:41 AM10/24/14
to Ira Cooke, harald.barsnes, gal...@umn.edu, mva...@gmail.com, cgue...@umn.edu, j...@umn.edu, tgri...@umn.edu
Hi Ira,

> Thanks for this info. I agree that it would be good to go for frequent updates (to avoid stagnation of the wrapper) … but the main issue is that with such frequent updates it’s often not feasible to thoroughly check the tool in between releases. It’s quite easy for a small change in the CLI to break the wrapper. Ideally we’d setup some automated testing for the wrapper .. (perhaps using planemo https://github.com/galaxyproject/planemo <https://github.com/galaxyproject/planemo> ) to ensure that our releases are not causing breakages.
>
> I think Bjorn already has some experience with Planemo … what do you think about this Bjoern?

Yes, this makes such stuff easier to setup. The current plan is to
integrate automatic testing and upload to the TS on the IUC repo. From
this we can take ideas and code to enable this also for the
peptide-shaker repository, or we just put it under IUC.

Comments welcome!

I really think we have a good Peptide Shaker wrapper. We need to split
the one wrapper into two ... and update the features. I don't think it
is much work, but I would like to have all different branches merged
that are floating around until I start to work on it again.

Cheers,
Bjoern

> Cheers
> Ira
>
>
>> On 24 Oct 2014, at 7:57 am, harald.barsnes <harald....@gmail.com> wrote:
>>
>>
>> Hi Pratik,
>>
>> PeptideShaker v0.35.0 and SearchGUI v1.22.0 have just been released! So I'd recommend going with these latest versions. :)
>>
>> Among the updates in the latest versions:
>> - Support for Comet (http://comet-ms.sourceforge.net <http://comet-ms.sourceforge.net/>). (Windows and Linux)
>> - Updated version of MS Amanda which now also is supported on Linux.*
>> - Complex PTM setups are now handled better.
>> - The processing of data in PeptideShaker is faster.
>>
>> * At least in theory. It requires the installation of Mono (http://www.mono-project.com <http://www.mono-project.com/>), and should be regarded as beta. But might be worth a shot, as the results from our testing so far look pretty good.
>>
>> As to the question of how often to update the SearchGUI and PeptideShaker versions in Galaxy, I'd say that once or twice a year sounds very infrequent. As you can see from our release notes we release new versions of our tools almost every month. Granted some of these are just minor updates and not all versions have to be wrapped for Galaxy. But if we wait half a year between each update then the versions in Galaxy will become fairly outdated compared to the standalone versions.
>>
>> However, updating to new versions of SearchGUI and PeptideShaker should usually not require any change to the command lines, and should in most cases be as easy as replacing the two jar files? So unless the rest of the job of wrapping SearchGUI and PeptideShaker is very time consuming I don't see why more frequent updates should be a problem?
>>
>> Best regards,
>> Harald
>>
>>
>>
>>
>> On Thursday, October 23, 2014 10:17:26 PM UTC+2, Pratik Jagtap wrote:
>> Hello Marc and Harald,
>>
>> Great News !
>>
>> While Candace is looking into 0.34 version outside of GalaxyP - we can discuss on plans to wrap the latest version of GalaxyP.
>>
>> Harald and Marc - when do you anticipate 0.35 version to be available? Would it be worthwhile to wait for the new version and wrap for GalaxyP usage or do you think proceeding with 0.34 would be okay?
>>
>> Ira and Bjoern - would you be able to wrap the latest version of PeptideShaker (0.34 or 0.35 when it is available) - so that it can be uploaded onto the new GalaxyP instance?
>>
>> Another decision we will have to make is on how frequently should PeptideShaker be Galaxy-wrapped? With frequent changes taking place we should make a decision on wrapping it once or twice a year. Any thoughts?
>>
>> Looking forward to this project progressing further.
>>
>> Regards,
>>
>> Pratik
>>
>> On Tue, Oct 21, 2014 at 4:13 AM, Marc Vaudel <mva...@gmail.com <javascript:>> wrote:
>> oops, sorry did not see that Harald already answered :)
>>
>> 2014-10-21 1:23 GMT+02:00 harald.barsnes <harald....@gmail.com <javascript:>>:
>>
>> Hi Candace,
>>
>> Ira is perfectly correct. In recent versions of PeptideShaker (starting from version 0.32.0) it is now possible to get all the required files in a single zip file by adding "-zip path_to_zip_file" to the PeptideShaker command line.
>>
>> The created zip file will contain the PeptideShaker cps file and a data folder with the required fasta and mgf files.
>>
>> As to the references to absolute paths, PeptideShaker will also look for the files in the same folder as the cps file and in any folders called "data". Or the user can provide missing files manually.
>>
>> Best regards,
>> Harald
>> (Sorry if this message appears more than once. I first tried to reply directly to the e-mail.)
>>
>>
>>
>> On Tuesday, October 21, 2014 12:47:23 AM UTC+2, iracooke wrote:
>> Hi Candace
>>
>> It's great news that you are working on this!! I believe that recent versions of peptide shaker and searchgui have implemented a feature whereby all necessary files are packaged into a zip. I haven't explored this at all myself though so I can't say much about the details.
>>
>> Best wishes
>>
>> Ira
>>
>>
>> Sent from my iPhone
>>
>> On 21 Oct 2014, at 7:31 am, Candace Guerrero <cgue...@umn.edu <>> wrote:
>>
>>> Hello Everyone,
>>>
>>> Let me introduce myself. I am Candace - a new post-doc in Tim's lab and I will be working on testing of PeptideShaker tool witin GalaxyP.
>>>
>>>
>>> I would like to give a short update for the PeptideShaker tool in GalaxyP 2014 (the latest version of GalaxyP). Currently, PeptideShaker can successfully use a single file or data set collection to generate all PeptideShaker output options. However, when trying to open the cps file in a desktop version of PeptideShaker it fails to open. We believe this is due to the inability for PeptideShaker to access other files needed and that would usually be stored in the same path. Because cps files are storing absolute paths, there is no way for the desktop viewer to access these files when using GalaxyP 2014. Is there a way to package all the needed files in to a large comprehensive Galaxy cps file so that a desktop version of Peptide Shaker could open it?
>>>
>>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> Candace
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups "Galaxy for Proteomics" group.
>>> To post to this group, send email to gal...@umn.edu <>.
>>> Visit this group at http://groups.google.com/a/umn.edu/group/galaxyp/ <http://groups.google.com/a/umn.edu/group/galaxyp/>.
>>> To view this discussion on the web visit https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAD0XxZxcMx1hprTvoxFvhwvk8UpB%3DS6dJDaXY2K%3DN1fTgEctMw%40mail.gmail.com <https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAD0XxZxcMx1hprTvoxFvhwvk8UpB%3DS6dJDaXY2K%3DN1fTgEctMw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send an email to galaxyp+u...@umn.edu <>.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Galaxy for Proteomics" group.
>> To post to this group, send email to gal...@umn.edu <javascript:>.
>> Visit this group at http://groups.google.com/a/umn.edu/group/galaxyp/ <http://groups.google.com/a/umn.edu/group/galaxyp/>.
>> To view this discussion on the web visit https://groups.google.com/a/umn.edu/d/msgid/galaxyp/e0595d17-a4f5-4f6b-b30e-132fa280460c%40umn.edu <https://groups.google.com/a/umn.edu/d/msgid/galaxyp/e0595d17-a4f5-4f6b-b30e-132fa280460c%40umn.edu?utm_medium=email&utm_source=footer>.
>>
>> To unsubscribe from this group and stop receiving emails from it, send an email to galaxyp+u...@umn.edu <javascript:>.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Galaxy for Proteomics" group.
>> To post to this group, send email to gal...@umn.edu <javascript:>.
>> Visit this group at http://groups.google.com/a/umn.edu/group/galaxyp/ <http://groups.google.com/a/umn.edu/group/galaxyp/>.
>> To view this discussion on the web visit https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAE1e1duUReRuAi%2BbjsTHNfTmb2fMsYCcyVK7mjg-EGqrPEvcmg%40mail.gmail.com <https://groups.google.com/a/umn.edu/d/msgid/galaxyp/CAE1e1duUReRuAi%2BbjsTHNfTmb2fMsYCcyVK7mjg-EGqrPEvcmg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>>
>
>

Marc Vaudel

unread,
Oct 24, 2014, 7:40:37 AM10/24/14
to Björn Grüning, Ira Cooke, harald.barsnes, Galaxy for Proteomics, Candace Guerrero, Jim Johnson, Timothy Griffin, pjagtap@umn.edu >> Pratik Jagtap
Hi Björn,

Good to hear back from you!

> Are there some test-data (small ones) that you regularly check?
Yes, as we have to maintain the tools tutorials as well (compomics.com/bioinformatics-for-proteomics), we test most functionalities manually for every release on the example dataset which comes with the software (click "open example" at start of the tool). When we make use case specific changes, we have test datasets adapted to these: low resolution, heavily modified, unspecific digestion, large datasets, exotic organism, datasets for evaluation of error rates, etc. or we just select one relevant in PRIDE (Click "Reshake" at start of the tool). But this is all manual work and I don't think that you should go into that kind of testing. 
I guess for you, as long as the command line runs, it is fine. For now, if the command line is incorrect, the tool will not start and an error message will be printed. If you like, I can make a test command line which will return a diagnostic file in case something goes wrong? Would this or something similar solve the problem?

Best regards,

Marc

Björn Grüning

unread,
Oct 24, 2014, 8:33:34 AM10/24/14
to Marc Vaudel, Ira Cooke, harald.barsnes, Galaxy for Proteomics, Candace Guerrero, Jim Johnson, Timothy Griffin, pjagtap@umn.edu >> Pratik Jagtap
Hi Marc!

Am 24.10.2014 um 13:40 schrieb Marc Vaudel:
> Hi Björn,
>
> Good to hear back from you!
>
>> Are there some test-data (small ones) that you regularly check?
> Yes, as we have to maintain the tools tutorials as well (
> compomics.com/bioinformatics-for-proteomics), we test most functionalities
> manually for every release on the example dataset which comes with the
> software (click "open example" at start of the tool). When we make use case
> specific changes, we have test datasets adapted to these: low resolution,
> heavily modified, unspecific digestion, large datasets, exotic organism,
> datasets for evaluation of error rates, etc. or we just select one relevant
> in PRIDE (Click "Reshake" at start of the tool). But this is all manual
> work and I don't think that you should go into that kind of testing.
> I guess for you, as long as the command line runs, it is fine. For now, if
> the command line is incorrect, the tool will not start and an error message
> will be printed. If you like, I can make a test command line which will
> return a diagnostic file in case something goes wrong? Would this or
> something similar solve the problem?

I don't think this is necessary.
What would help us is a small test input data with the corresponding
expected result + all argument that were used to create such results.
With such a set, we can automatically test if the Galaxy wrapper is
working. Galaxy will diff, the expected result with the calculated
results and if everything is ok, the wrapper is supposed to work. We can
also check file sizes.

Thanks,
Bjoern

Marc Vaudel

unread,
Oct 24, 2014, 8:37:31 AM10/24/14
to Björn Grüning, Ira Cooke, harald.barsnes, Galaxy for Proteomics, Candace Guerrero, Jim Johnson, Timothy Griffin, pjagtap@umn.edu >> Pratik Jagtap
Hi again!

OK that sounds great, I will come back to you next week with a small test dataset :)

Best regards,

Marc

Ira Cooke

unread,
Oct 24, 2014, 4:55:40 PM10/24/14
to Björn Grüning, harald.barsnes, gal...@umn.edu, mva...@gmail.com, cgue...@umn.edu, j...@umn.edu, tgri...@umn.edu
Hi Bjoern, 

Great to hear from you. My preference would be to keep this as a separate repository as this will keep the commit history sensible (ie not filled with commits to other IUC tools), and will also mean that we can have our own wiki etc on bitbucket or github.   

In order to do automated testing with travis .. and to keep things similar to the IUC repo maybe we should move to github though.  If we do that I am happy to host the “master” repo on my account.

Currently the repository situation is that the “Master” is;


I have a fork at 


but my fork is in sync with Bjoerns.

Cheers
Ira
Reply all
Reply to author
Forward
0 new messages