ConTeXt Modules help

Introduction

Please note: the current version of the website is preliminary, and much can still be improved. Suggestions and bug reports are welcome.

If something is not working right or if you have an idea how something can be made to work better, please send an email message to the mailing list.

Module creation

Details on various form fields are given below.

When you create a new module, a short wizard will present itself to help you set up the module.

The Module ID field is the internal identifier of the module. It should consist of a single 'word' with a length of at least two characters that only contains alphanumerics, dashes, and underscores.

Module editing

Title: This is the official human-readable name of your module, also used for the zip archive file name. One word, no spaces; dashes and underscores are ok. May be the same as the ID.
Short description: This is a description in one sentence of what the module does. This is e.g. used in CTAN news.
Long description: This is an optional longer description in a few sentences.
Home URL: If you maintain an independent website for this modules, you can add the link here.
Module type: A module is usually a Macro module; in MkII there were also Font modules. (The distinction is important because the required module source structure is different for each type.) For font support in MkIV/LMTX, please publish typescripts in the wiki.
License: Pick one from the dropdown. If you need to use a different license, please drop an email, the list is probably incomplete.
Log message: This field is just for release notes: it will not be exported to anywhere. The SVN URL and GIT URL methods will automatically overwrite this field with the remote revision and log message. For other source methods, you can fill in whatever seems appropriate.
Version: This is the user-visible version field. Please do not use spaces, because the version is also used in creating the released archive file, and spaces in filenames are cumbersome. Most version strings are dates in the format YYYY.MM.DD. It should be the same as the content of the VERSION file.

Source upload screen

Here it gets interesting. There are four ways to get the source of a module release into the database, as explained in the next sections.

Please note: Currently only the zip, tar.gz and tar.xz archive formats are supported in the File upload and HTTP URL methods, and there are strict requirements on the archive itself:

For a Macro module, it should contain a complete TDS subtree. In distributions, all macro files go under texmf-* (e.g. texmf-modules), so that directory level must be skipped in the archive. Be warned that in general, uploading a CTAN zipped folder will NOT work, because CTAN modules are almost never in TDS format.
Make sure your archive contains only files that belong to your module, and especially that it does not accidentally overwrite files owned by other modules.
We accept no responsibility for module contents: the system does run some sanity checks, but ultimately, you as the maintainer are responsible for creating a correctly functioning module. Badly behaving or non-working modules can be removed on executive decision by the maintainer without prior notice.

As previous revision: If you are editing an already existing module, then it is possible to re-use the uploaded source from the revision you are editing as the source for the new revision that will be created.
File upload: Upload of a local archive file via CGI. Be warned that if there are other errors in your form, you will have to re-select the local file after fixing those other errors. Contrary to the other fields, local file selection is not persistent across form submits.
HTTP URL: This asks the system to do a wget download of an archive file from a specific URL, which could be either HTTP(S) or FTP. If you need remote login information to access the file, please encode the user name and password in the URL, exactly as you would do when using wget on the command line.
SVN URL: This asks the system to do a svn checkout from a specific URL. In this case, you may also need SVN username and SVN password. Also, some repositories may need anonymous as user name for anonymous access. The top-level checkout folder will be stripped away before creating the module. This is so that you can give something like http://foundry.supelec.fr/svn/metapost/trunk/texmf/ as URL without getting an extra directory level.
GIT URL: This asks the system to do a git clone from a specific https URL. In this case, you may also need GIT Branch.; Note: you cannot use any git protocol except (anonymous) https. If you try any other protocol, the git clone command that is started by the webserver will attempt to do an interactive input query and will subsequently fail.
module contents: Please check this carefully! TLContrib does some sanity checking, but it does not check the actual contents of any of the files, nor can it test everything.

Module transfer

It is possible for the maintainer of a module to transfer the module to another user completely. To do so, follow the Share link in your module list. See the help text in that form for details.

Module sharing

It is possible for the maintainer of a module to share the module maintenance with other users.

To set up module sharing for a module you maintain, follow the Share link in your module list. See the help text in that form for details.

When someone else has shared a module with you, then you will see new entries in your module list. These will have the user id of the actual module maintainer added after the Date field. You can edit such modules (and thus create new revisions), but the new revisions will become property of the actual module maintainer.

In other words: a module can only have one actual maintainer, and that maintainer is responsible for all revisions of the module. However, the maintainer can allow other users to help with the actual creation of new revisions.

Module deletion

In the list of your modules and in the view screen of one of your module releases, there are two links that delete items:

Del / Delete revision: This link deletes a single revision of a module.
Nuke: This link removes a whole module completely, including all revisions of it.

Both links show a confirmation screen first.

Navigation