A list for the developers of CellML tools

Text archives Help


[cellml-dev] [cellml-discussion] CellML API 1.10rc1 available now


Chronological Thread 
  • From: ak.miller at auckland.ac.nz (Andrew Miller)
  • Subject: [cellml-dev] [cellml-discussion] CellML API 1.10rc1 available now
  • Date: Wed, 07 Sep 2011 08:27:39 +1200

On 31/08/11 19:04, Alan Garny wrote:
> Hi Andrew,
>
> Thanks a lot for 1.10rc1. Just a few questions/requests, if you don't mind:
> - Would it be possible to have different names for the Linux .tar.bz2
> files? Right now, both the x86 and x64 versions have the same name. No big
> deal, of course, but still it would be nice.

Hi Alan,

I've committed a change that will add i686 and x86_64 to the filenames;
I'll be trying it out shortly, once I've made sure all the other
feedback is addressed.

> - More importantly, for me, is the wish for a compressed version of the
> Mac
> OS X binary. Right now, you are offering a .dmg file which I am not
> interested in, sorry...

I'm a bit concerned that we are getting a proliferation of different
packages, and it is getting out of hand.

There are ongoing costs per package:
1. it increases the time and amount of disk space needed to build the
snapshots, and so has an ongoing cost in terms of ABI computational
resources.
2. every time a snapshot is made, it is uploaded to Sourceforge. It
therefore costs the ABI a certain amount for bandwidth per format per
snapshot.
3. storage on Sourceforge is presumably a finite resource with some
(unknown) limit - the more formats we have, the sooner we will have to
start pruning back snapshots.
4. every released file has to be manually entered into the release
system at present; it therefore takes a certain amount of extra human
time for the person making each release / release candidate per format.
5. every API user downloading the API implementation has to read
through all the options and decide which file to download. We want to
have enough options to keep users satisfied, but not have choices that
they may consider meaningless as that would be wasting their time and
creating an artificial barrier to them adopting the API.

Therefore, we definitely want to have a good justification for each new
packaging format we add. As I see it, DMG is the most standard way to
distribute binary packages for the Mac, and it is easy to get the files
out either from the UI or programmatically.

It is relatively easy to convert a .dmg to a .tar.bz2, for example - you
can do this:
cd /tmp/
http_proxy=proxy.bioeng.auckland.ac.nz:8080 wget
http://sourceforge.net/projects/cellml-api/files/CellML-API-Nightly/1.10/20110905/mac/cellml-sdk-1.10-Mac.dmg/download
# Note - this makes you accept the license with rc1 - but I'm working on
that so it can be completely automated.
hdiutil attach -mountpoint /tmp/cellml-sdk-mount cellml-sdk-1.10-Mac.dmg
-quiet
cp -R ./cellml-sdk-mount/CellML\ SDK\ 1.10.app/Contents/Resources cellml-sdk
hdiutil detach cellml-sdk-mount
tar -cjf cellml-sdk.tar.bz2 cellml-sdk
rm -fr ./cellml-sdk

Given how easy it is to convert between .dmg and .tar.bz2, and that most
API users on Mac should be happy with the .dmg, I think we need a strong
justification why it would be helpful to add yet another option - could
you please elaborate on why a .dmg is not sufficient for your needs?

Best wishes,
Andrew




Archive powered by MHonArc 2.6.18.

Top of page