Re: Remove the binary distributions?

On 10 December 2011 03:26, Kevin Reid <[email protected]> wrote:
> On Sep 27, 2011, at 5:25, Thomas Leonard wrote:
>
>> There's quite a lot of complexity (and slowness) in the E build for
>> producing platform-specific releases (e.g. E-win32-x86-0.9.3a.zip). Is
>> anybody using these?
>
> I can't speak for anyone else, but I have in the past used the Mac SWT releases while trying to get SWT to work. This little use case would probably be better served by a little note about "where to get SWT", but see below.
>
>> How would people feel about having a single E release (just puredist),
>> without any jars? This means that people writing SWT applications would
>> be responsible for distributing swt.jar with their application somehow
>> (e.g. using a Maven pom.xml, a 0install feed, or bundling a copy).
>
> In theory, SWT is to be the standard GUI library for EoJ. *.e-swt scripts (such as those included in the EoJ distribution) should just work out of the box.
>
> In practice, considering that SWT is native code where the rest of E isn't, and variously platform/version-dependent, I think it would be OK to say "get SWT <prominent link to specific instructions here> if you want to use these GUI programs".
>
> Possibly relevant: I am in favor of simplifying EoJ's build process.
>
> Higher-level point: I think we should reconsider to what degree we want to be writing E programs that are tied to Java at all.
>
>> We could make the rune "run" command depend on SWT in the 0install feed
>> so that the SWT example scripts continue to work without extra effort
>> (for people using 0install). That would avoid making every E program
>> depend on SWT (e.g. headless servers). People not using 0install or a
>> distribution package manager would need to install SWT for their
>> platform manually.
>
> I need some context.
>
> Who uses 0install other than you?

In general, people use 0install when the program they're trying to run uses it.

If you want figures, it's hard to say. Each distribution has its own
package in its repository with its own stats. e.g. for Debian:

http://qa.debian.org/popcon.php?package=zeroinstall-injector

Though what these figures mean I'm not entirely sure. I think it's
estimating that 0.67% of Debian users currently have it installed.

sf.net says we have had 137,362 downloads in total, but that includes
all the tools too, not just the main 0install program.

> What do you mean by 'the rune "run" command'? Rune does not have anything I would consider subcommands.

When you launch a program, 0install runs the "run" command by default.
e.g. these run e-core's "run" command:

$ 0launch http://repo.roscidus.com/e/e-core
?

or

$ 0alias rune http://repo.roscidus.com/e/e-core
$ rune
?

In e-core's XML, it looks like this:

    <command name="run">
      <runner interface="http://repo.roscidus.com/java/openjdk-6-jre">
	<arg>-De.home=$EHOME</arg><arg>org.erights.e.elang.interp.Rune</arg>
      </runner>
    </command>

Currently, this gets you a non-SWT version of E. We could provide an
extra "run-swt" entry-point, e.g.

    <command name="run-swt">
      <runner interface="http://repo.roscidus.com/java/openjdk-6-jre">
	<arg>-De.home=$EHOME</arg><arg>org.erights.e.elang.interp.Rune</arg>
      </runner>
      <requires interface="http://repo.roscidus.com/java/swt">
        <environment insert="swt.jar" name="CLASSPATH"/>
      </requires>
    </command>

Then you could do:

$ 0launch --command=run-swt http://repo.roscidus.com/e/e-core

Or we could do it the other way around, having "run" and
"run-headless" commands.

> My understanding of 0install is that package are identified with their entry points. If rune depends on SWT, how do you get headless E without SWT?

There are a couple of options:

1. E programs can specify e-core as their <runner>. By having multiple
commands as above and using a command-specific dependency, programs
can set their <runner> to "run" or "run-swt". So an E program might
declare its runner as e-core, like this:

    <command name='run' path='myprog.e'>
      <runner interface="http://repo.roscidus.com/e/e-core" command='run'/>
    </command>

By changing the command name in the <runner>, the program could select
the SWT or headless commands in e-core.

2. An E program can specify Java as its <runner> and e-core as a
library. In that case, none of e-core's runners is used. Then SWT can
be added as any other dependency. For example:

      <command name='run' path='myprog.e-swt'>
	<runner interface='http://repo.roscidus.com/java/openjdk-6-jre'>
	  <arg>-De.home=$EHOME</arg><arg>org.erights.e.elang.interp.Rune</arg>
	</runner>
      </command>
      <requires interface="http://repo.roscidus.com/e/e-core">
	<environment name="CLASSPATH" insert="e.jar"/>
	<environment name="EHOME" insert="" mode='replace'/>
      </requires>
      <requires interface='http://repo.roscidus.com/java/swt'>
	<environment name='CLASSPATH' insert='swt.jar'/>
      </requires>

Although longer, it means that SWT isn't a special case. Also, this
way allows you to pass extra Java options (e.g. heap size), and you
have to give the dependencies explicitly if you want to set version
contraints (e.g. SWT >= 3.6). This is the method we currently use.

It probably depends whether you care about the Java integration (we
do). The first form hides the fact that it's using Java.


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang