[t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

Paul Menzel

1 May 2011 1 May '11

12:18 p.m.

Dear Philipp and ConTeXt folks, what needs to be done, that the module t-rst [1] can be installed using the following command. $ ./first-setup.sh --extras="t-rst" (I. e. how can this module be included into the ConTeXt Minimals distribution?) Thanks, Paul [1] https://bitbucket.org/phg/context-rst

Attachments:

signature.asc (application/pgp-signature — 198 bytes)

Show replies by date

Mojca Miklavec

1 May 1 May

1:18 p.m.

On Sun, May 1, 2011 at 12:18, Paul Menzel wrote:

...

Dear Philipp and ConTeXt folks,

what needs to be done, that the module t-rst [1] can be installed using the following command.

$ ./first-setup.sh --extras="t-rst"

1a. Somebody needs to check/confirmed that it is well-formed. 1b. At least somebody needs to find it useful and request it (which you just did; should it also be added to TeX Live?). 2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful). Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live). Mojca

pmlists＠free.fr

2:33 p.m.

New subject: [t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

Mojca Miklavec writes:

...

2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful).

Indeed, very painful ... ;) I'm sure, that the module authors would like to run just one simple command (e.g. "make contrib-upload") to update their modules in the distribution, instead of filling a form in a web-browser. Suggestion: to make it easy and fast, why not just add a new svn directory to foudry.supelec.fr, and every author gets a sub-directory, where they can upload their modules in TDS format. And the first-setup.sh would just pull the modules from there. Thus the authors can keep using bitbucket, github, etc. for their daily work, and upload a new version by means of a new makefile-target. -- Peter

Mojca Miklavec

2:37 p.m.

On Sun, May 1, 2011 at 14:33, Peter Münster wrote:

...

Suggestion: to make it easy and fast, why not just add a new svn directory to foudry.supelec.fr, and every author gets a sub-directory, where they can upload their modules in TDS format. And the first-setup.sh would just pull the modules from there. Thus the authors can keep using bitbucket, github, etc. for their daily work, and upload a new version by means of a new makefile-target.

We'll continue the discussion with Taco today. (I have set up SVN repository also on the garden, but whatever option is chosen, it would be great to keep everything at a single place at the end.) Mojca

Aditya Mahajan

4:14 p.m.

On Sun, 1 May 2011, Mojca Miklavec wrote:

...

1a. Somebody needs to check/confirmed that it is well-formed.

To clarify, by well-formed you mean that it follows TDS; not the quality of the module, right? Aditya

Mojca Miklavec

2 May 2 May

7:58 a.m.

On Sun, May 1, 2011 at 16:14, Aditya Mahajan wrote:

...

On Sun, 1 May 2011, Mojca Miklavec wrote:

...
1a. Somebody needs to check/confirmed that it is well-formed.

To clarify, by well-formed you mean that it follows TDS; not the quality of the module, right?

Preferrably both. However TDS and some other fixed rules are easy to check. Checking the quality is much harder. Proper form of a module is a requirement. A decent level of quality is desired. Mojca

Philipp Gesang

4 May 4 May

7 p.m.

Hi Paul, Mojca & others, sorry for the late answer, I was cut off from the list for a couple of days. On 2011-05-01 <13:18:05>, Mojca Miklavec wrote:

...

On Sun, May 1, 2011 at 12:18, Paul Menzel wrote:

...
Dear Philipp and ConTeXt folks,

what needs to be done, that the module t-rst [1] can be installed using the following command.

$ ./first-setup.sh --extras="t-rst"

1a. Somebody needs to check/confirmed that it is well-formed.

New version 0.3 conforms with the module/namespacing guidelines. (Thanks to Wolfgang for his valuable suggestions.) As to the quality … I’ll be happy to apply any patches.

...

1b. At least somebody needs to find it useful and request it (which you just did; should it also be added to TeX Live?).

What would the inclusion into TL imply?

...

2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful).

If it’s possible now I’d try it asap.

...

Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live).

Looks like context needs a package manager. (Something like Arch’s PKGBUILDs, stored on the garden, could simplify the minimals’ installation procedure a great deal.) Best regards Philipp PS: Paul, thanks for the patches (was the same diff twice, wasn’t it?).

...

Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Aditya Mahajan

5 May 5 May

12:02 a.m.

On Wed, 4 May 2011, Philipp Gesang wrote:

...

Looks like context needs a package manager. (Something like Arch’s PKGBUILDs, stored on the garden, could simplify the minimals’ installation procedure a great deal.)

https://github.com/adityam/context-pkgbuild (but this only installs the modules available with --extras=all). Aditya

Philipp Gesang

11:47 a.m.

On 2011-05-04 <18:02:44>, Aditya Mahajan wrote:

...

On Wed, 4 May 2011, Philipp Gesang wrote:

...
Looks like context needs a package manager. (Something like Arch’s PKGBUILDs, stored on the garden, could simplify the minimals’ installation procedure a great deal.)

https://github.com/adityam/context-pkgbuild

(but this only installs the modules available with --extras=all).

Yes, I know and though I prefer the minimals installer, you already got my vote. Would be no problem to write module pkgbuilds for arch. But the minimals need to be cross platform. (Pkgbuilds use bash syntax -- however, context already brings its own cross-platform interpreter, namely lua. Maybe the module repositories should provide installation directives, written as a lua table, that could then be fed to texlua? The installer would thus 1. clone/pull the repo to somewhere safe (file integrity check done implicitly by git/hg); 2. “dofile” the install file and 3. move the files to their designated paths; possibly 4. build the documentation. (Module dependencies could make this all a lot more difficult in the end.)) tl;dr lua might help. Philipp

...

Aditya

...

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Mojca Miklavec

6 May 6 May

8:55 p.m.

On Wed, May 4, 2011 at 19:00, Philipp Gesang wrote:

...

...
1b. At least somebody needs to find it useful and request it (which you just did; should it also be added to TeX Live?).

What would the inclusion into TL imply?

That people using TeX Live could also install it.

...

...
2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful).

If it’s possible now I’d try it asap.

Did you have any problems? In case you did, please contact Patrick.

...

...
Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live).

Looks like context needs a package manager.

Do you have any suggestion how it should look like and how it should work? mtx-update is kind-of package manager, but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI). Mojca

Aditya Mahajan

9:04 p.m.

...

...
Looks like context needs a package manager.

Do you have any suggestion how it should look like and how it should work? mtx-update is kind-of package manager, but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

Similar to ruby gems or perl cpan or even texlive tlmgr. Ideally, a user should be able to do: package-manager search "keyword" and get a list of modules and package-manager install "modulename" and be able to install the module (without updating the whole installation). Additional niceties like package-manager make "module" for preparing a zip file that can be uploaded to contextgarden will be nice. ctxtools does provide the last functionality, but you need a tpm file for that, while tlcontrib wants a module to be submitted without a tpm file. Aditya

Marco

9:08 p.m.

On 2011-05-06 Mojca Miklavec wrote:

...

...
Looks like context needs a package manager.

[...] but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

There are several possibilities, GTK+ is well documented, ported to many platforms and operating systems (However, maybe not to all, ConTeXt supports) and has Lua bindings. Marco

Mojca Miklavec

7 May 7 May

5:36 p.m.

On Fri, May 6, 2011 at 21:08, Marco wrote:

...

On 2011-05-06 Mojca Miklavec wrote:

...
...
Looks like context needs a package manager.

[...] but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

There are several possibilities, GTK+ is well documented, ported to many platforms and operating systems (However, maybe not to all, ConTeXt supports) and has Lua bindings.

If you can prepare a very simple example and explain how to compile it on windows, mac and windows ... Mojca

Taco Hoekwater

8 May 8 May

1:18 p.m.

On 05/07/2011 05:36 PM, Mojca Miklavec wrote:

...

On Fri, May 6, 2011 at 21:08, Marco wrote:

...
On 2011-05-06 Mojca Miklavec wrote:

...
...
Looks like context needs a package manager.

[...] but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

There are several possibilities, GTK+ is well documented, ported to many platforms and operating systems (However, maybe not to all, ConTeXt supports) and has Lua bindings.

If you can prepare a very simple example and explain how to compile it on windows, mac and windows ...

Installing the *right* GTK+ version on macosx is quite a challenge. The texlive way of perl/Tk is much more portable, even though it re-introduces perl to the mix. Another option could be to use a http browser, using Hans' mtxrun web server and client? That is pure lua, but of course it is not available until after installation of context. Best wishes, Taco

Marco

4:17 p.m.

On 2011-05-08 Taco Hoekwater wrote:

...

...
...
There are several possibilities, GTK+ is well documented, ported to many platforms and operating systems (However, maybe not to all, ConTeXt supports) and has Lua bindings.

If you can prepare a very simple example and explain how to compile it on windows, mac and windows ...

Installing the *right* GTK+ version on macosx is quite a challenge.

I don't know, I never used macosx.

...

The texlive way of perl/Tk is much more portable, even though it re-introduces perl to the mix.

I don't think it's a good idea to introduce perl. The way to go is to get rid of the hotchpotch of languages and implement everything in lua, if possible. If we prefer TK over GTK why not use the lua Tk bindings? Marco

Pontus Lurcock

9:43 p.m.

New subject: [t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

On Sun 08 May 2011, Marco wrote:

...

If we prefer TK over GTK why not use the lua Tk bindings?

When I saw this discussion starting I googled the Lua Tk bindings, and it turned out [1] that they apparently haven't been updated since 1998. A shame, since Tk is usually a good bet for easy cross-platform GUIs. [1] http://www.tecgraf.puc-rio.br/~celes/tklua/ Pont

Marco

10:07 p.m.

New subject: GUI for minimals WAS: Re: [t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

On 2011-05-09 Pontus Lurcock wrote:

...

On Sun 08 May 2011, Marco wrote:

...
If we prefer TK over GTK why not use the lua Tk bindings?

When I saw this discussion starting I googled the Lua Tk bindings, and it turned out [1] that they apparently haven't been updated since 1998.

What about ltcltk [1], it's from 2010? However I never used it, I just did some simple GUIs with the GTK+ binding. [1] http://www.tset.de/ltcltk/ Marco

Taco Hoekwater

9 May 9 May

10:03 a.m.

New subject: GUI for minimals WAS: Re: [t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

On 05/08/2011 10:07 PM, Marco wrote:

...

On 2011-05-09 Pontus Lurcock wrote:

...
On Sun 08 May 2011, Marco wrote:

...
If we prefer TK over GTK why not use the lua Tk bindings?

When I saw this discussion starting I googled the Lua Tk bindings, and it turned out [1] that they apparently haven't been updated since 1998.

What about ltcltk [1], it's from 2010? However I never used it, I just did some simple GUIs with the GTK+ binding.

There is a real, serious problem with the predictability of GTK+ installations on macosx. It feels like each version of macosx in either 32 or 64 bit needs a different version of the bundle, and on top of that it hard to predict which one is needed. Installation of any GTK+ bundle always appears to work, but if you have the wrong one the runtime crashes. Best wishes, Taco

Arthur Reutenauer

8 May 8 May

4:56 p.m.

...

Another option could be to use a http browser, using Hans' mtxrun web server and client? That is pure lua, but of course it is not available until after installation of context.

We could bootstrap the system by first downloading only the necessary pieces, like is done for the Minimals. It should only need half a dozen files. But all that needs to be actually developed, of course. Arthur

Hans Hagen

7:36 p.m.

On 8-5-2011 4:56, Arthur Reutenauer wrote:

...

...
Another option could be to use a http browser, using Hans' mtxrun web server and client? That is pure lua, but of course it is not available until after installation of context.

We could bootstrap the system by first downloading only the necessary pieces, like is done for the Minimals. It should only need half a dozen files. But all that needs to be actually developed, of course.

can someone remind me what problem we're trying to solve here? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

Mojca Miklavec

8:17 p.m.

On Sun, May 8, 2011 at 19:36, Hans Hagen wrote:

...

On 8-5-2011 4:56, Arthur Reutenauer wrote:

...
...
Another option could be to use a http browser, using Hans' mtxrun web server and client? That is pure lua, but of course it is not available until after installation of context.

We could bootstrap the system by first downloading only the necessary pieces, like is done for the Minimals. It should only need half a dozen files. But all that needs to be actually developed, of course.

can someone remind me what problem we're trying to solve here?

Having a GUI installer for the minimals (to make it more user-friendly and enable the user to choose what modules and fonts to install). Mojca

Marco

11 p.m.

On 2011-05-08 Mojca Miklavec wrote:

...

On Sun, May 8, 2011 at 19:36, Hans Hagen wrote:

...
On 8-5-2011 4:56, Arthur Reutenauer wrote:

...
...
Another option could be to use a http browser, using Hans' mtxrun web server and client? That is pure lua, but of course it is not available until after installation of context.

We could bootstrap the system by first downloading only the necessary pieces, like is done for the Minimals. It should only need half a dozen files. But all that needs to be actually developed, of course.

can someone remind me what problem we're trying to solve here?

Having a GUI installer for the minimals (to make it more user-friendly and enable the user to choose what modules and fonts to install).

Just a (maybe stupid) idea: What about making the existing windows GUI install and/or update all available modules/fonts, since most windows users don't care about a few hundred MiB disk space. Second, creating a repository for Debian/Ubuntu that enables Linux users to install the minimals using the system package manager. It's easy to create a package for the modules. I have no idea how package management works for MacOS, if something like repositories exist or how software is installed/updated. And leave the existing interface for the other platforms, since the vast majority uses either Linux, Windows or MacOS. Marco

Thomas A. Schmitz

11:28 p.m.

New subject: [t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

On May 8, 2011, at 11:00 PM, Marco wrote:

...

...
Having a GUI installer for the minimals (to make it more user-friendly and enable the user to choose what modules and fonts to install).

Just a (maybe stupid) idea:

What about making the existing windows GUI install and/or update all available modules/fonts, since most windows users don't care about a few hundred MiB disk space.

Second, creating a repository for Debian/Ubuntu that enables Linux users to install the minimals using the system package manager. It's easy to create a package for the modules.

I have no idea how package management works for MacOS, if something like repositories exist or how software is installed/updated.

And leave the existing interface for the other platforms, since the vast majority uses either Linux, Windows or MacOS.

Just a few thoughts: 1. linux ≠ ubuntu/debian. Maintaining a repository for all different linux distros in their different package formats would be a nightmare. 2. Maintaining a cross-platform GUI is incredibly difficult. gtk is an absolute non-starter on OS X. 3. Resources are limited. I would rather they go into development of luatex and mkiv then into eye-candy for mouse-pushers. 4. We now get reports from people (not necessarily, but sometomes newbies) going "I ran command X, and the output was Y." With a GUI we get: "I pushed the button, you know the one with the letters on it, and nothing happened." GUIs have a tendency to hide useful information, making debugging all but impossible. (I sometimes look at comp.text.tex on usenet - the number of people who confuse their editor and its shiny interface with the underlying TeX engine is staggering; the same would happen here). 5. Even if it's "easy" to create a debian package for the modules, who's going to create and maintain it? 6. Offering a GUI sends out a wrong message to new users: it pretends that this is just something that will work the same way as their word processor or office program works. But once people actually want to do useful things, they need to learn a minimum of coding techniques. Users will then feel deceived because the shiny GUI made them believe they could just write away and click buttons. In sum: I see no compelling reason in favor of, but many important reasons against such an installer. Thomas

Marco

9 May 9 May

12:17 a.m.

On 2011-05-08 "Thomas A. Schmitz" wrote:

...

On May 8, 2011, at 11:00 PM, Marco wrote:

...
...
Having a GUI installer for the minimals (to make it more user-friendly and enable the user to choose what modules and fonts to install).

Just a (maybe stupid) idea:

What about making the existing windows GUI install and/or update all available modules/fonts, since most windows users don't care about a few hundred MiB disk space.

Second, creating a repository for Debian/Ubuntu that enables Linux users to install the minimals using the system package manager. It's easy to create a package for the modules.

I have no idea how package management works for MacOS, if something like repositories exist or how software is installed/updated.

And leave the existing interface for the other platforms, since the vast majority uses either Linux, Windows or MacOS.

Just a few thoughts:

1. linux ≠ ubuntu/debian. Maintaining a repository for all different linux distros in their different package formats would be a nightmare.

ACK.

...

2. Maintaining a cross-platform GUI is incredibly difficult. gtk is an absolute non-starter on OS X.

If you say so. But anyway, we should not discuss about which GUI toolkit we use, since it is not at all decided that anything will change at this point.

...

3. Resources are limited. I would rather they go into development of luatex and mkiv then into eye-candy for mouse-pushers.

4. We now get reports from people (not necessarily, but sometomes newbies) going "I ran command X, and the output was Y." With a GUI we get: "I pushed the button, you know the one with the letters on it, and nothing happened." GUIs have a tendency to hide useful information, making debugging all but impossible. (I sometimes look at comp.text.tex on usenet - the number of people who confuse their editor and its shiny interface with the underlying TeX engine is staggering; the same would happen here).

I agree. My thought was the following: The installation/update of ConTeXt is not integrated into the systems default methods. How often do we get installation help requests on the mailing list (on every platform)! Supporting the default installation/update method of the operating system would not necessarily need a GUI and be easy for the users.

...

5. Even if it's "easy" to create a debian package for the modules, who's going to create and maintain it?

The creation of the package is scriptable. When the module developer uploads/updates a module a (not yet existing) script is called that creates the Debian package, which is saved in the repository. Of course a scriptable solution breaks when e.g. dependencies are not met.

...

6. Offering a GUI sends out a wrong message to new users: it pretends that this is just something that will work the same way as their word processor or office program works. But once people actually want to do useful things, they need to learn a minimum of coding techniques. Users will then feel deceived because the shiny GUI made them believe they could just write away and click buttons.

In sum: I see no compelling reason in favor of, but many important reasons against such an installer.

As said before: Supporting the native package installation mechanisms of the major OSs/distributions would be a big help. For the rest the present mechanisms work fine. Marco

Marco

8 May 8 May

4:01 p.m.

On 2011-05-07 Mojca Miklavec wrote:

...

On Fri, May 6, 2011 at 21:08, Marco wrote:

...
On 2011-05-06 Mojca Miklavec wrote:

...
...
Looks like context needs a package manager.

[...] but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

There are several possibilities, GTK+ is well documented, ported to many platforms and operating systems (However, maybe not to all, ConTeXt supports) and has Lua bindings.

If you can prepare a very simple example and explain how to compile it on windows, mac and windows ...

A simple example of a GUI is attached and may serve as a starting point (questions to the example maybe better off-list, since it's not at all ConTeXt related). I don't know which packages are required on windows or macos. On linux and solaris it is sufficient to install GTK and the lua-gtk bindings. Marco

Philipp Gesang

7 May 7 May

12:19 p.m.

Hi Mojca & all, On 2011-05-06 <20:55:59>, Mojca Miklavec wrote:

...

On Wed, May 4, 2011 at 19:00, Philipp Gesang wrote:

...
...
1b. At least somebody needs to find it useful and request it (which you just did; should it also be added to TeX Live?).

What would the inclusion into TL imply?

That people using TeX Live could also install it.

True, but I was, rather selfishly, thinking about what it would imply for the module author. Permanent maintenance of one release over a year? Is it really worth it? After all, most people who come to this list asking for help with their TL context are advised to switch to the minimals.

...

...
...
2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful).

If it’s possible now I’d try it asap.

Did you have any problems? In case you did, please contact Patrick.

I did have problems about a year ago. Probably tomorrow--- depending on the weather---I’ll add an xml interface file and comment the module source. After that I’ll give the upload another shot.

...

...
...
Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live).

Looks like context needs a package manager.

...

Do you have any suggestion how it should look like and how it should work? mtx-update is kind-of package manager, but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

The GUI would be the last thing I’d start worrying about. Basically it would have to receive a list of locations and the respective VCS, like for instance: :: t-filter, git, https://github.com/adityam/filter.git transliterator, hg, https://bitbucket.org/phg/transliterator Then it would call the VCS to checkout the tip (or latest tag or whatever). Each should have a “.install.lua” in the base dir containing instructions about where the files should go. (Best thing is, probably, that no compilation is necessary because everything’s plain text.) A local register could contain version information, filenames, paths etc. of the modules installed. But that’s just musings as I don’t have a clue what restrictions other OS might put on file attributes (does luafs get rid of these?). Someone with experience on all the main three platforms could really help here. Philipp

...

Mojca ___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

Wolfgang Schuster

1:23 p.m.

New subject: [t-rst] inclusion into Minimals, i. e. installation using `./first-setup.sh --extras='t-rst'`

Am 07.05.2011 um 12:19 schrieb Philipp Gesang:

...

Hi Mojca & all,

...
...
What would the inclusion into TL imply?

That people using TeX Live could also install it.

True, but I was, rather selfishly, thinking about what it would imply for the module author. Permanent maintenance of one release over a year? Is it really worth it? After all, most people who come to this list asking for help with their TL context are advised to switch to the minimals.

The problem with texlive inclusion is that you can’t use new features from context which aren’t available in the texlive version, e.g. \definenamespace was added after the texlive 2010 freeze and therefore you can’t use the command for modules which are on ctan and texlive.

...

...
...
...
Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live).

Looks like context needs a package manager.

...
Do you have any suggestion how it should look like and how it should work? mtx-update is kind-of package manager, but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

The GUI would be the last thing I’d start worrying about. Basically it would have to receive a list of locations and the respective VCS, like for instance: ::

t-filter, git, https://github.com/adityam/filter.git transliterator, hg, https://bitbucket.org/phg/transliterator

Then it would call the VCS to checkout the tip (or latest tag or whatever). Each should have a “.install.lua” in the base dir containing instructions about where the files should go. (Best thing is, probably, that no compilation is necessary because everything’s plain text.) A local register could contain version information, filenames, paths etc. of the modules installed.

+1 But when we have should a file it shouldn’t be requires to have a TDS for the project files because it’s a mess to work on a module when you have so many subdirectories. When you take a look at one of my modules [1] you can see that all my source files under “files” directory and i create the zip with the correct paths from a tex file. When you can something similar with Lua and a text file everything is perfect. [1] https://bitbucket.org/wolfs/annotation/src Wolfgang

Philipp Gesang

2:08 p.m.

On 2011-05-07 <13:23:18>, Wolfgang Schuster wrote:

...

Am 07.05.2011 um 12:19 schrieb Philipp Gesang:

...
Hi Mojca & all,

...
...
What would the inclusion into TL imply?

That people using TeX Live could also install it.

True, but I was, rather selfishly, thinking about what it would imply for the module author. Permanent maintenance of one release over a year? Is it really worth it? After all, most people who come to this list asking for help with their TL context are advised to switch to the minimals.

The problem with texlive inclusion is that you can’t use new features from context which aren’t available in the texlive version, e.g. \definenamespace was added after the texlive 2010 freeze and therefore you can’t use the command for modules which are on ctan and texlive.

...
...
...
...
Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live).

Looks like context needs a package manager.

...
Do you have any suggestion how it should look like and how it should work? mtx-update is kind-of package manager, but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

The GUI would be the last thing I’d start worrying about. Basically it would have to receive a list of locations and the respective VCS, like for instance: ::

t-filter, git, https://github.com/adityam/filter.git transliterator, hg, https://bitbucket.org/phg/transliterator

Then it would call the VCS to checkout the tip (or latest tag or whatever). Each should have a “.install.lua” in the base dir containing instructions about where the files should go. (Best thing is, probably, that no compilation is necessary because everything’s plain text.) A local register could contain version information, filenames, paths etc. of the modules installed.

+1

But when we have should a file it shouldn’t be requires to have a TDS for the project files because it’s a mess to work on a module when you have so many subdirectories.

When you take a look at one of my modules [1] you can see that all my source files under “files” directory and i create the zip with the correct paths from a tex file. When you can something similar with Lua and a text file everything is perfect.

[1] https://bitbucket.org/wolfs/annotation/src

Yes, I know that. But symlinks to a testing directory do the trick as well; but that’s another OS specific matter … The install instructions would probably have to look like [1] = { "./subdir/file1.ext", "target/dir/in/ctx/tree/file1.ext", "md5sum" }, So it would work either way. (The md5 could be redundand due to VCS already hashing stuff.) Philipp

...

Wolfgang

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : http://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___________________________________________________________________________________

-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

Mojca Miklavec

5:45 p.m.

On Sat, May 7, 2011 at 12:19, Philipp Gesang wrote:

...

...
...
What would the inclusion into TL imply?

That people using TeX Live could also install it.

True, but I was, rather selfishly, thinking about what it would imply for the module author. Permanent maintenance of one release over a year? Is it really worth it? After all, most people who come to this list asking for help with their TL context are advised to switch to the minimals.

To me personally it doesn't imply anything special. When I update the module for minimals, it is automatically updated on CTAN for MikTeX and TeX Live as well. It is true that my module is not using much of bleeding edge technology; but when it does, I do not care about TeX Live's ConTeXt compatibility too much. Still, having the module in TeX Live means that when I occasionally do use TeX Live, the modules I might need are available there as well.

...

...
...
...
2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful).

If it’s possible now I’d try it asap.

Did you have any problems? In case you did, please contact Patrick.

I did have problems about a year ago. Probably tomorrow--- depending on the weather---I’ll add an xml interface file and comment the module source. After that I’ll give the upload another shot.

I keep my finders crossed for you. :)

...

...
...
...
Once 1 and 2 are met, I just add a single line to sources that trigger inclusion of the module to minimals (and a separate one for inclusion into TeX Live).

Looks like context needs a package manager.

...
Do you have any suggestion how it should look like and how it should work? mtx-update is kind-of package manager, but I admit that I miss some GUI (but then again I have no idea how to write a portable GUI).

The GUI would be the last thing I’d start worrying about. Basically it would have to receive a list of locations and the respective VCS, like for instance: ::

t-filter, git, https://github.com/adityam/filter.git transliterator, hg, https://bitbucket.org/phg/transliterator

Then it would call the VCS to checkout the tip (or latest tag or whatever). Each should have a “.install.lua” in the base dir containing instructions about where the files should go. (Best thing is, probably, that no compilation is necessary because everything’s plain text.) A local register could contain version information, filenames, paths etc. of the modules installed.

All the needed modules are already in the garden. (Or are supposed to be on the garden at least.) It is way easier to maintain them all at a single source and then all users can fetch them from that single source than to redirect each user to repository for which one might not even have the necessary software installed (missing hg binary for example). It is true that at the moment you cannot switch to an older version of the module, but that is a slightly unrelated issue that has to be solved somewhat globaly (it is usually a much more serious problem that one cannot roll back ConTeXt version). Mojca

Philipp Gesang

8 May 8 May

8:32 p.m.

On 2011-05-07 <17:45:47>, Mojca Miklavec wrote:

...

On Sat, May 7, 2011 at 12:19, Philipp Gesang wrote:

...
...
...
...
2. Until we do something about it, it would be very very desirable to put it to modules.contextgarden.net (I know that it is painful).

If it’s possible now I’d try it asap.

Did you have any problems? In case you did, please contact Patrick.

I did have problems about a year ago. Probably tomorrow--- depending on the weather---I’ll add an xml interface file and comment the module source. After that I’ll give the upload another shot.

I keep my finders crossed for you. :)

Looks like it worked now: http://modules.contextgarden.net/rst Have fun, Philipp -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4976

Age (days ago)

4984

Last active (days ago)

List overview

Download

29 comments

12 participants

participants (12)

Aditya Mahajan
Arthur Reutenauer
Hans Hagen
Marco
Mojca Miklavec
Paul Menzel
Philipp Gesang
pmlists＠free.fr
Pontus Lurcock
Taco Hoekwater
Thomas A. Schmitz
Wolfgang Schuster