Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes= $env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
$env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together.
If that is still satisfying I would clean up my code and create a pull request [1]. What do you think?
Cheers, Bjoern
[1] or patch, I heard rumours that you do not like pull requests ;)?
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
Hi Björn,
This is great. A pull request or a patch is fine. Whatever one is most convenient for you. The code doesn't have to be pretty, just functional. We can always pretty it up later.
Thanks very much for doing this!
Greg
On Jul 7, 2013, at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes=$env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
$env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together.
If that is still satisfying I would clean up my code and create a pull request [1]. What do you think?
Cheers, Bjoern
[1] or patch, I heard rumours that you do not like pull requests ;)?
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
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/
Hi Greg,
bitbucket has a downtime so I have attached a patch. I will create tomorrow a pull request if I find time.
It will work as described and we have now a new variable (__is64bit__) that we can use to determine if python is running under 64bit (assuming that the rest is also 64bit-ish).
Attached is a ported version of emboss as test case (Dave B wrapper).
Have a nice evening! Bjoern
Hi Björn,
This is great. A pull request or a patch is fine. Whatever one is most convenient for you. The code doesn't have to be pretty, just functional. We can always pretty it up later.
Thanks very much for doing this!
Greg
On Jul 7, 2013, at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes= $env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
$env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together.
If that is still satisfying I would clean up my code and create a pull request [1]. What do you think?
Cheers, Bjoern
[1] or patch, I heard rumours that you do not like pull requests ;)?
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
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/
Hello Björn,
Thanks very much for the patch - I've committed alsightly alterered verson of it in changetset 10204:afec613d77fa which is currently running on the test tool shed.
Greg Von Kuster
On Jul 7, 2013, at 6:59 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi Greg,
bitbucket has a downtime so I have attached a patch. I will create tomorrow a pull request if I find time.
It will work as described and we have now a new variable (__is64bit__) that we can use to determine if python is running under 64bit (assuming that the rest is also 64bit-ish).
Attached is a ported version of emboss as test case (Dave B wrapper).
Have a nice evening! Bjoern
Hi Björn,
This is great. A pull request or a patch is fine. Whatever one is most convenient for you. The code doesn't have to be pretty, just functional. We can always pretty it up later.
Thanks very much for doing this!
Greg
On Jul 7, 2013, at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes= $env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
$env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together.
If that is still satisfying I would clean up my code and create a pull request [1]. What do you think?
Cheers, Bjoern
[1] or patch, I heard rumours that you do not like pull requests ;)?
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
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/
<tool_dependencies.xml><template_command.patch>___________________________________________________________ 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/
Björn,
I've uploaded the modified tool_dependencies.xml to devteam's package_emboss_5_0_0 repository on the test tool shed, and verified that it works. Again, thank you for your contributions.
--Dave B.
On 7/7/13 18:59:57.000, Björn Grüning wrote:
Hi Greg,
bitbucket has a downtime so I have attached a patch. I will create tomorrow a pull request if I find time.
It will work as described and we have now a new variable (__is64bit__) that we can use to determine if python is running under 64bit (assuming that the rest is also 64bit-ish).
Attached is a ported version of emboss as test case (Dave B wrapper).
Have a nice evening! Bjoern
Hi Björn,
This is great. A pull request or a patch is fine. Whatever one is most convenient for you. The code doesn't have to be pretty, just functional. We can always pretty it up later.
Thanks very much for doing this!
Greg
On Jul 7, 2013, at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes= $env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
$env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together.
If that is still satisfying I would clean up my code and create a pull request [1]. What do you think?
Cheers, Bjoern
[1] or patch, I heard rumours that you do not like pull requests ;)?
Thanks for looking into this!
Greg Von Kuster
On Jul 7, 2013, at 5:50 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi,
I was thinking how to tackle the build failures like the atlas library on OS-X or the ones from xlib and ease the writing of the shell_command a little bit.
Dave B did some fancy shell scripting in 'package_emboss_5_0_0' and I was also sometimes forced to use some bash tricks.
What about to make that more easy and powerful, and as a plus more consistent with the tool-command tag, and use cheetah for that kind of work.
Something like that could work easily:
#if ${os.environ}.getVar('X11_LIB_DIR', None): ./configure ... --x-includes=.... #else: ./configure #end if
Also we could define some reserved variables like $__is64__ and cheetah evaluate that. $INSTALL_DIR and $REPOSITORY_DIR can also be a cheetah variable and we do not need to replace it later manually.
What do you think any comments? If no one has any objections I can try to implement an <action type="cheetah_command">.
Thanks, Björn
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/
Hi Dave,
Björn,
I've uploaded the modified tool_dependencies.xml to devteam's package_emboss_5_0_0 repository on the test tool shed, and verified that it works. Again, thank you for your contributions.
Great, thanks!
--Dave B.On 7/7/13 18:59:57.000, Björn Grüning wrote:
Hi Greg,
bitbucket has a downtime so I have attached a patch. I will create tomorrow a pull request if I find time.
It will work as described and we have now a new variable (__is64bit__) that we can use to determine if python is running under 64bit (assuming that the rest is also 64bit-ish).
Attached is a ported version of emboss as test case (Dave B wrapper).
Have a nice evening! Bjoern
Hi Björn,
This is great. A pull request or a patch is fine. Whatever one is most convenient for you. The code doesn't have to be pretty, just functional. We can always pretty it up later.
Thanks very much for doing this!
Greg
On Jul 7, 2013, at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi Greg,
Hello Björn,
This would be great! I'm not sure about the type attribute - <action type="cheetah_command" may be ok, but maybe a more generic type like <action type="template_command" would be better. I'm not quite sure, so go with what you feel is best.
I come up with the following:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes= $env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
$env is the global access point to the env variables and its working fine for the few repositories I tested it. I had hoped to get it a little bit prettier but fabric and cheetah doesn't work well together.
If that is still satisfying I would clean up my code and crea
It probably makes sense to specify the template type in this case. Maybe an additional attribute, language='cheetah' ?
On Sun, Jul 7, 2013 at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes=$env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
-- James Taylor, Assistant Professor, Biology/CS, Emory University
Hi James,
It probably makes sense to specify the template type in this case. Maybe an additional attribute, language='cheetah' ?
My first suggestion was <action type="cheetah_command"> to reflect the template engine. I'm fine with both.
On Sun, Jul 7, 2013 at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes=$env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
-- James Taylor, Assistant Professor, Biology/CS, Emory University
I'll soon be committing a slightly altered version of your patch which includes a language attribute for the template_command action type.
On Jul 8, 2013, at 10:02 AM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
Hi James,
It probably makes sense to specify the template type in this case. Maybe an additional attribute, language='cheetah' ?
My first suggestion was <action type="cheetah_command"> to reflect the template engine. I'm fine with both.
On Sun, Jul 7, 2013 at 1:19 PM, Björn Grüning bjoern.gruening@pharmazie.uni-freiburg.de wrote:
<action type="template_command"> #if env.get('X11_LIB_DIR', False) and env.get('X11_INCLUDE_DIR', False): ./configure --prefix=$env.INSTALL_DIR --x-includes=$env.X11_INCLUDE_DIR --x-libraries=$env.X11_LIB_DIR #else: ./configure --prefix=$env.INSTALL_DIR #end if </action>
-- James Taylor, Assistant Professor, Biology/CS, Emory University
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/
galaxy-dev@lists.galaxyproject.org
-
Björn Grüning -
Dave Bouvier -
Greg Von Kuster -
James Taylor