source: project/wiki/releasing-your-egg @ 38781

Last change on this file since 38781 was 38781, checked in by ewfalor, 7 months ago

Correct syntax of usage example

File size: 26.1 KB
Line 
1== Releasing your egg
2
3[[toc:]]
4
5Let's say you've been reading the [[eggs tutorial]] and you are almost
6done writing your first egg.  You've tested that it works locally, and
7now you probably want to make it available to others.  If you would
8like people to be able to install your egg using {{chicken-install YOUR-EGG}},
9there are a few steps you need to take.
10
11=== Note for Subversion users
12
13Before going on details on the process for Subversion,
14please note that hosting '''new''' eggs in the '''CHICKEN central
15Subversion repository''' is '''deprecated'''.  We recommend using
16your own code server or one of the hosts available on the Internet
17(e.g., github, bitbucket etc.).
18
19If you host your egg on {{code.call-cc.org}} or you host your own,
20you don't ''have'' to do any of the steps below.  Instead, you can
21use the release generating script at call-cc.org.  It does all the
22steps below automatically.
23
24The URI for an automatically generated release-info for egg YOUR-EGG is
25{{http://code.call-cc.org/release-info?egg=YOUR-EGG}}
26
27This URI can be put in the {{egg-locations}} file as described under
28[[#publishing-your-egg|"Publishing your egg"]].
29
30If you want more control over the process, please read on.
31
32=== Creating a release-info file
33
34First, you must create a so-called "release-info" file and make it
35available on a well-known location via HTTP (discussed below).  This
36is a file which describes where the released versions of your egg can
37be found.
38
39After everything's set up, releasing a new version of your egg is
40simply a matter of tagging your release with your VCS of choice and
41adding a line to this file. See [[#helper-scripts|below]] for some tools
42to automate even this small step.
43
44It looks something like this:
45
46<enscript highlight="scheme">
47(repo git "git://example.com/{egg-name}.git")   ; optional
48
49(uri targz "http://example.com/{egg-name}/releases/{chicken-release}/{egg-name}-{egg-release}.tar.gz")
50(release "0.1")
51(release "0.2")
52(release "1.0")
53</enscript>
54
55This example describes where to find the canonical repository and an URI pattern
56which describes how to find release tarballs.  It then goes on to declare three
57official releases; 0.1, 0.2 and 1.0.
58
59The patterns in the URI enclosed in curly braces are seen as
60substitution patterns to be replaced by values.  {{egg-name}} expands
61to the current egg's name (which is already known when the
62release-info file is being fetched), {{egg-release}} is replaced by
63the string in each {{release}} declaration.  {{chicken-release}} is
64replaced by the major CHICKEN version for which the egg is being
65fetched.  This allows you to supply different packages for each major
66CHICKEN release.
67
68The supported types for {{uri}} are currently {{targz}}, {{tarbz2}}, {{zip}},
69{{meta-file}} and {{files-list}}.  The first three are all archives expected
70to extract to a directory with the egg sources in it (zip files are allowed
71to expand directly into the files, but this is not recommended).  The latter
72two are special and deserves some more explanation; see the next section for that.
73
74Currently {{repo}} is not used by automated tools, but is intended to
75make it easy for users to find the repository.  In preparation for
76when it will be used in the future, it's a good idea to use consistent
77names, so please use the ''short name'' of the tool.  Generally this is
78how it is invoked on the commandline: {{git}}, {{hg}}, {{svn}}, {{fossil}}, {{bzr}}, {{mtn}}, {{darcs}} etc.
79
80==== Meta-file distribution
81
82Sometimes it is impractical to create archives containing your egg's file
83contents.  The egg releasing system has been designed to require as few manual
84steps as possible, so it is easy for people to release early and often.
85
86A core ideal of the release system is to make it possible to release
87simply by tagging your code in a VCS.  Some code hosting sites
88automatically make archives available for each tagged version, thereby
89making the release available immediately when the code is pushed to
90the server.  For those that don't, the meta-file distribution file
91type is a way to release by tagging ''without'' having to manually
92make a tarball, ''as long as there is a way to directly obtain the raw
93sources of a specific release version via HTTP''.
94
95The idea is that each released egg always must have a meta-file to describe
96its dependencies, its author and license and so on.  This meta-file can be
97used to provide a listing of all the files that are part of an egg.  The system
98that manages egg releases automatically will download all these files and put
99them in a directory.  When someone requests your egg with {{chicken-install}},
100these files are all served up.  Just add a {{files}} entry to your meta-file,
101which lists the files (these are resolved relatively to the meta-file itself).
102
103<enscript highlight="scheme">
104((files "uri-common.setup" "uri-common.release-info" "uri-common.meta"
105        "uri-common.scm" "tests/run.scm")
106 (license "BSD")
107 (category web)
108 (depends (uri-generic 2.3) defstruct matchable)
109 (test-depends test)
110 (author "Peter Bex")
111 (synopsis "Parser for common URI schemes"))
112</enscript>
113
114This is a real-world example of the [[/eggref/4/uri-common|uri-common egg]].
115It lists all the files which it consists of, and these will be downloaded by
116chicken-install.  The disadvantage of this approach is that if you forget a
117file, your egg is uninstallable, so if you can please use the archive
118distribution types instead.  Another disadvantage is that every time you add,
119remove or rename a file you need to remember to change the meta-file.
120
121The {{uri}} entry in uri-common's {{release-info}} file looked like this
122before there was an autogenerated one:
123
124<enscript highlight="scheme">
125(uri meta-file "http://anonymous@code.call-cc.org/svn/chicken-eggs/release/{chicken-release}/{egg-name}/tags/{egg-release}/{egg-name}.meta")
126</enscript>
127
128Because this egg uses subversion and each release has a corresponding
129tag, it can simply point to the metafile in the right subdirectory
130under tags and it will simply work.  For other version systems this
131may require some more messing around.
132
133==== files-list
134
135This is an extremely stupid format containing a manifest of files in
136an egg.  It's mostly useful when automatically generating lists of files.
137It starts with a base URI and then lists all the files in the egg.
138Here's the [[http://code.call-cc.org/files-list?egg=uri-generic;egg-release=1.0;chicken-release=4|files-list for version 1.0 of the uri-generic egg for CHICKEN 4]]:
139
140  http://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/uri-generic/tags/1.0
141  tests/run.scm
142  uri-generic.meta
143  uri-generic.scm
144  uri-generic.setup
145
146The trailing slash after the URI is required.
147
148It's not recommended you use this manually, as this format is subject
149to change and only really intended to be used as a communication system
150between [[/eggref/4/pseudo-meta-egg-info|pseudo-meta-egg-info]] and
151[[/eggref/4/henrietta-cache|henrietta-cache]].
152
153However, if you really need to use this, you can replace the
154{{meta-file}} uri type in the example above by {{files-list}}, like
155the auto-generated
156[[http://code.call-cc.org/release-info?egg=uri-generic|release-info file for uri-generic]],
157which starts like this:
158
159  (uri files-list "http://code.call-cc.org/files-list?egg={egg-name};egg-release={egg-release};chicken-release={chicken-release}")
160  (release "1.0")
161  (release "1.1")
162
163=== Publishing your egg
164
165After creating the release-info file, you need to make it known to the
166chicken-install infrastructure that an egg with the given name has a
167release info file at the location where you published it.  This step finally
168makes it possible for people to say {{chicken-install YOUR-EGG}} and have
169it install your egg, or use {{(depends YOUR-EGG)}} in meta-files of their eggs.
170
171Currently this is done by adding a line to the egg-locations file in
172Subversion, which can be found at
173[[https://code.call-cc.org/svn/chicken-eggs/release/4/egg-locations]]. For security reasons, editing the {{egg-locations}} file requires special permissions.  So, to have an entry for your egg in that file, send a message to the [[http://lists.nongnu.org/mailman/listinfo/chicken-users|chicken-users mailing list]] announcing your egg and requesting the inclusion of its location to {{egg-locations}}.
174
175To keep maintenance to a minimum, it's best to add a release-info
176location which will never change; only the release-info file itself
177should be changed when you make a new release.  This can most easily
178be accomplished by pointing to the "raw file" view of your
179trunk/tip/head/master branch in your canonical repository's web
180interface.  That way, this file is kept under version control
181alongside all the other files in your egg.
182
183If you do have an svn account and don't want to checkout the whole egg
184repository to be able to just edit this file, you can work around svn's
185limitations like this:
186
187 $ cd /tmp
188 $ svn co https://code.call-cc.org/svn/chicken-eggs/release/4 --depth empty
189 $ cd 4
190 $ svn update egg-locations
191
192If you prefer, you can just publish the file separately via HTTP
193somewhere and keep overwriting it.  If your code hoster doesn't
194provide an easy way to point to a raw view on a moving "latest
195version" pointer via HTTP, you could instead opt to store just the
196release-info files of your eggs in the centralised CHICKEN eggs
197subversion repository.  Just contact one of the project maintainers or
198write to the chicken-users mailinglist.
199
200=== Instructions for popular code hosting methods and VCSes
201
202Now we've explained the basic idea, here's an overview of how to figure
203out the correct URIs and how to automate some steps away.
204
205==== Bitbucket (mercurial, git)
206
207===== Location of release-info file
208
209You can use the code browser to figure out the path to your
210release-info file.  First, copy the link that says "raw".  This URI is
211almost correct but will contain a revision ID hash, so it is pinned to
212whatever revision is currently the tip.  However, you can replace it
213with the string "tip" and it will still work, and when you visit it again
214after making changes it will have picked up those changes.  Example:
215
216Clicking "mini-kanren.release-info" and then copying the "raw" link on
217[[https://bitbucket.org/ThatGeoGuy/chicken-minikanren/src]] gives us
218[[https://bitbucket.org/ThatGeoGuy/chicken-minikanren/raw/8af0b51f5efac79c8bc0cfe856185ad06d7aa9d0/mini-kanren.release-info]]
219
220Just change it to
221[[https://bitbucket.org/ThatGeoGuy/chicken-minikanren/raw/master/mini-kanren.release-info]]
222and you have the latest master version.  If you're using Mercurial
223instead of git, use {{tip}} instead of {{master}}.
224
225This link should be registered in the egg-locations list for your egg
226and it will automatically be able to fetch any new releases as they
227are tagged and added to the release-info file.
228
229===== Making releases
230
231The bitbucket code browser also offers a "get source" link that allows
232you to fetch the files in that revision as a tarball.  The same trick
233as with the raw files works here; just replace the link's revision ID
234hash with a symbolic name.  You can use tags and bookmarks as symbolic
235names.
236
237So to make a new release, just tag your release with a well-defined
238name. If you tag your eggs with the version as tag or bookmark name,
239you can use the following release-info file.  Just don't forget to
240substitute your bitbucket username!
241
242<enscript highlight="scheme">
243(repo hg "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}")
244(uri targz "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}/get/{egg-release}.tar.gz")
245(release "0.1")
246</enscript>
247
248==== GitLab (git)
249
250===== Location of release-info file
251
252Use the code browser ("Files" in the menu) to browse to your master
253branch's release-info file and copy the "Raw" link.  For example, for
254the [[/eggref/4/sdl2|SDL2 egg]] it looks like this:
255
256[[https://gitlab.com/chicken-sdl2/chicken-sdl2/raw/master/sdl2.release-info]]
257
258===== Making releases
259
260GitLab makes tags available for download as tarballs.  To find the
261location, go to the code browser and switch to a tag at the top left.
262On the right side there's a drop-down menu that offers a download for
263various archive formats.
264
265So to make a new release, just tag your release with a well-defined
266name. If you're using gitlab.com's hosted service and tag your eggs
267with the version as tag name, you can use the following release-info
268file.  Just don't forget to substitute your GitLab project name!
269
270<enscript highlight="scheme">
271(repo git "https://gitlab.com/PROJECT-NAME/{egg-name}.git")
272(uri targz "https://gitlab.com/PROJECT-NAME/{egg-name}/repository/archive.tar.gz?ref={egg-release}")
273(release "0.1")
274</enscript>
275
276
277==== GitHub (git)
278
279===== Location of release-info file
280
281Use the code browser ("source" tab) to browse to your release-info
282file and copy the "raw" link.  This link should work as-is, as long as
283you do this while looking at the latest revision of the file in the
284master branch.  For example, for the [[/eggref/4/kalaha|Kalaha egg]]
285it would look like:
286
287[[https://raw.github.com/DerGuteMoritz/kalaha/master/kalaha.release-info]]
288
289===== Making releases
290
291GitHub makes tags available for download as tarballs.  To find the
292location, click the big "Downloads" button/link in the code browser.
293It will pop up a selection dialog where you can choose between tarball
294and "zipball".  It will also offer downloads for each tag, but those
295are zipballs only.  However, you can copy the link and replace
296"zipball" in the URL by "tarball", or you can first click "switch
297tags" and then open the "Downloads" dialog and it will offer you
298download links for both tar and zip for that specific tag.
299
300So to make a new release, just tag your release with a well-defined
301name. If you tag your eggs with the version as tag name, you can use
302the following release-info file.  Just don't forget to substitute your
303GitHub username!
304
305<enscript highlight="scheme">
306(repo git "git://github.com/YOUR-GITHUB-USERNAME/{egg-name}.git")
307(uri targz "https://codeload.github.com/YOUR-GITHUB-USERNAME/{egg-name}/tar.gz/{egg-release}")
308(release "0.1")
309</enscript>
310
311
312==== Gitweb (git)
313
314===== Location of release-info file
315
316Navigate to the "tree" view for the master branch of your project and
317copy the "raw" link for your release-info file. The link will look
318something like this, for an egg "foo":
319
320 http://gitweb/gitweb.cgi?p=foo.git;a=blob_plain;f=foo.release-info
321
322===== Making releases
323
324The download link for a tarball of a specific Git tag is accessible
325through Gitweb with a query string like the following:
326
327 http://gitweb/gitweb.cgi?p={egg-name}.git;a=snapshot;h=refs/tags/{egg-release};sf=tgz
328
329So, if you tag each release and use a release-info file like the
330following, every new tag will be made available as a tarball at that URL
331(make sure to substitute your Git URL and Gitweb host into {{repo}}
332and {{uri}} strings):
333
334<enscript highlight="scheme">
335(repo git "git://gitweb/{egg-name}.git")
336(uri targz "http://gitweb/gitweb.cgi?p={egg-name}.git;a=snapshot;h=refs/tags/{egg-release};sf=tgz")
337(release "0.1")
338</enscript>
339
340
341==== Sourcehut (mercurial, git)
342
343===== Location of release-info file
344
345For a Git repository, navigate to the "tree" view for the master branch
346of your project, select your release-info file and copy the "View raw"
347link from that page. The URL will look something like this, for user
348"user" and egg "example":
349
350 https://git.sr.ht/~user/example/blob/master/release-info
351
352For a Mercurial repository, go to your project's "browse" tab, select
353your release-info file and copy the "View raw" link. The URL should look
354like this:
355
356 https://hg.sr.ht/~user/example/raw/release-info
357
358===== Making releases
359
360Sourcehut provides download URLs for tags in both Mercurial and Git
361repositories. So, in either case you can make a new release by simply
362tagging your egg.
363
364If you use version numbers as tag names, you can use the following
365release-info files, replacing "USERNAME" with your own. Note the leading
366tilde, which must be included!
367
368For Git:
369
370<enscript highlight="scheme">
371(repo git "https://git.sr.ht/~USERNAME/{egg-name}")
372(uri targz "https://git.sr.ht/~USERNAME/{egg-name}/archive/{egg-release}.tar.gz")
373(release "0.1")
374</enscript>
375
376For Mercurial:
377
378<enscript highlight="scheme">
379(repo git "https://hg.sr.ht/~USERNAME/{egg-name}")
380(uri targz "https://hg.sr.ht/~USERNAME/{egg-name}/archive/{egg-release}.tar.gz")
381(release "0.1")
382</enscript>
383
384
385==== Cgit (git)
386
387===== Location of release-info file
388
389Navigate to the "tree" view for the master branch of your project and
390copy the "plain" link for your release-info file (it's all the way to
391the right). The link will look something like this, for an egg "foo":
392
393 http://cgit.example.com/foo/plain/foo.release-info
394
395For example, the release info for the [[/eggref/4/hardwood|Hardwood
396egg]] looks like this:
397
398[[http://www.upyum.com/cgit.cgi/hardwood/plain/hardwood.release-info]]
399
400The {{cgit.cgi}} part is optional, depending on how cgit was
401configured.  For example, the release-info for the
402[[/eggref/4/scsh-process|scsh-process egg]] looks like this:
403
404[[http://code.more-magic.net/scsh-process/plain/scsh-process.release-info]]
405
406===== Making releases
407
408The download link for a tarball of a specific Git tag can be found by
409visiting "refs", then the tag, following it to the commit and if
410snapshots are shown there should be a download link, but it links
411directly to the commit hash.  You can simply replace the hash with the
412symbolic tag name.
413
414If snapshots are not shown, it's still possible to construct the link
415manually, and it will work:
416
417 http://cgit.example.com/cgit.cgi/{egg-name}/snapshot/{egg-name}-{egg-release}.tar.gz
418
419So, if you tag each release and use a release-info file like the
420following, every new tag will be made available as a tarball at that
421URL (make sure to substitute your Git URL and Cgit host into
422{{repo}} and {{uri}} strings):
423
424<enscript highlight="scheme">
425(repo git "http://cgit.example.com/cgit.cgi/{egg-name}")
426(uri targz "http://cgit.example.com/{egg-name}/snapshot/{egg-name}-{egg-release}.tar.gz")
427(release "0.1")
428</enscript>
429
430==== hgweb (mercurial) - aka "hg serve"
431
432The built-in web interface for mercurial can be used to serve up eggs,
433usually invoked from hgweb and hgwebdir on a "real" server.
434
435===== Location of release-info file
436
437Use the browser to navigate to the latest revision of the release-info
438file and click the "raw" link on the left.  Then replace the commit ID
439hash with "tip".  Example:
440
441[[http://example.com/my-egg/raw-file/tip/my-egg.release-info]]
442
443===== Making releases
444
445Since this interface doesn't have a way to serve up tarballs, you must
446either create your own tarballs and publish them elsewhere or use the
447manual "meta-file" way.
448
449See [[#meta-file-distribution|the meta-file section]] at the start of
450this wiki page to figure out how to set up a {{files}} section in your
451meta-file.  The URI to your meta file is similar to the release-info
452file, except this time you can replace "tip" with the release's
453tagname.  If you use tagnames that are identical to the release
454version, you can base the release-info file on the following example:
455
456<enscript highlight="scheme">
457(repo hg "http://example.com/{egg-name}")
458(uri meta-file "http://example.com/{egg-name}/raw-file/{egg-release}/{egg-name}.meta")
459(release "0.1")
460</enscript>
461
462This assumes hgwebdir is running on the domain's root URI and the egg
463is available in a repo which has the same name as your egg.
464
465==== Fossil's default web UI
466
467This is the web UI you get when running "fossil serve" or when running
468fossil as a CGI script.
469
470There is one tricky part: by default, this interface disallows almost
471all outside access; you ''must'' log in, even if you just want to
472browse anonymously. To allow everybody to download release zipfiles or
473tarballs without login, add the "z" permission for the user "nobody"
474in the Admin / Users section of the web UI or with the "fossil user
475capabilities" command.
476
477===== Location of release-info file
478
479Fossil's web UI allows serving of documents directly from the
480repository under URLs of the form
481"http://example.com/my-egg/doc/{version}/{file}". If the files have a
482".txt" or ".wiki" extension, they are rendered into HTML, but anything
483else is served as is.
484
485For example you can store the release-info file in the repository and
486always access the latest version of the default branch at a URL like
487"http://example.com/my-egg/doc/trunk/my-egg.release-info".
488
489===== Making releases
490
491Fossil can serve tarballs or zipfiles of repository snapshots. A
492release-info file using zipfile packaging may look like this:
493
494<enscript highlight="scheme">
495(repo fossil "http://example.com/{egg-name}")
496(uri zip "http://example.com/{egg-name}/zip/{egg-name}.zip?uuid=v{egg-release}")
497(release "1.0.0")
498</enscript>
499
500For tarball packaging, the equivalent {{uri}} entry should look like
501this:
502
503<enscript highlight="scheme">
504(uri targz "http://example.com/{egg-name}/tarball/{egg-name}.tar.gz?uuid=v{egg-release}")
505</enscript>
506
507The releases are referenced using symbolic tags of the form
508"v{egg-release}" here. You can add these tags to the changesets
509corresponding to released versions of the egg using the "fossil tag
510add" command.
511
512==== Launchpad (bazaar)
513
514Unfortunately, Launchpad doesn't currently seem very suitable for
515developing eggs in a streamlined way.  Here's a description of one
516possible way to integrate with their way of doing release management though.
517
518===== Location of release-info file
519
520You can browse to the release-info file using Loggerhead (the web
521interface to bazaar), but there doesn't seem to be a reliable way to
522construct a raw download URI for "the latest version of" a file.
523
524A workaround is to create a release series just for the release-info,
525and make an (unused) milestone for that.  Then you can upload a
526release-info file.  The URI that's listed directly on the downloads
527page is stable though (something like
528[[http://launchpad.net/my-project/main/release-info/+download/my-egg.release-info]]
529if you named the milestone "release-info" in the "main" series)
530This link redirects to an unstable URI, so don't paste that one!
531
532When you make a new release you can ''delete'' the file and upload a new
533one manually to the same pseudo-"release".
534
535
536===== Making releases
537
538If you do it through their release management, you just create release
539tarballs which you manually upload into the release milestone.
540
541The only automation here is that you can use {{bzr export --format=tgz}}
542to create it, and the advantage that you're using someone else's site to
543host your code.
544
545You can use this release-info file template if you are consistent in
546your milestone naming.  It assumes you used the name "main" for the
547series from which releases for chicken-install are made.  You could
548alternatively add several {{uri}} entries, one per series, but it's
549still required that your egg's release versions are unique for your
550egg.  Series are probably more suitable for distinguishing between
551major CHICKEN release versions.
552
553<enscript highlight="scheme">
554(repo bzr "lp:MY-PROJECT/main")
555
556(uri targz "http://launchpad.net/MY-PROJECT/main/{egg-release}/+download/{egg-name}.tar.gz")
557(release "0.1")
558(release "0.2")
559</enscript>
560
561
562=== Helper scripts
563
564To make life easier, there are some helper scripts, hooks etcetera
565that could be used.  Please add your own links here.
566
567==== Subversion
568
569There's an [[/eggref/4/svn-egg-author|svn-egg-author egg]] that helps
570you to update the release-info and meta files and tag a release of
571your egg, all with one command.
572
573If you run your own subversion server with Spiffy, you can consider
574using [[/eggref/4/pseudo-meta-egg-info|pseudo-meta-egg-info]] instead.
575If you do, you do not need to use svn-egg-author.  If you're using the
576chicken-eggs repository hosted on call-cc.org, you don't need it either
577because call-cc is already running pseudo-meta-egg-info for all its eggs.
578
579==== Mercurial
580
581There's an
582[[http://code.more-magic.net/hg-egg-author/plain/egg-author.py|egg-author]]
583extension for Mercurial that allows you to say {{hg eggtag 0.1}} and have it
584automatically update the release-info file with the new tag name.
585
586==== Git
587
588There's a [[/eggref/4/git-egg-author|git-egg-author egg]] that helps you
589keep your release-info file up-to-date and tag a release with one command.
590
591==== Bazaar
592
593There's also a [[https://launchpad.net/bzr-egg-author|bzr-egg-author]]
594extension for Bazaar that allows you to say {{bzr eggtag 0.1}} and have it
595automatically update the release-info file with the new tag name.
596
597=== Moving an egg
598
599When you decide to migrate to a different code hosting site, and don't
600want to move all releases, you can define multiple uris:
601
602<enscript highlight="scheme">
603;; Main ("default") repo
604(repo hg "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}")
605(uri targz "https://bitbucket.org/YOUR-BITBUCKET-USERNAME/{egg-name}/get/{egg-release}.tar.gz")
606(release "2.1")
607(release "2.0")
608
609;; Old repo, using "old-svn-repo" alias
610(repo svn "http://anonymous:@code.call-cc.org/svn/chicken-eggs/release/4/{egg-name}")
611(uri files-list "http://code.call-cc.org/files-list?egg={egg-name};egg-release={egg-release};chicken-release={chicken-release}" old-svn-repo)
612(release "1.3" old-svn-repo)
613(release "1.2" old-svn-repo)
614(release "1.1" old-svn-repo)
615(release "1.0" old-svn-repo)
616(release "0.2" old-svn-repo)
617(release "0.1" old-svn-repo)
618</enscript>
619
620
621=== Testing new eggs before publishing them
622
623The initial setup of a new egg is relatively tricky.  Some details have to be
624properly configured before the official release.  For example:
625
626* The .release-info file must be publicly available, so that [[/egg/henrietta-cache|henrietta-cache]] can access it.
627* The syntax of the .release-info file must be correct, and the releases and tarballs it points to must be consistent.
628* The egg code must be compilable and installable.  Usually you test it from the local source code repository, which can be in a different state from the remote source repository -- that leads to problems when making the egg available.
629* The egg metadata must be properly specified (e.g., dependencies) -- that's another thing that can cause problems if the egg is tested with the CHICKEN installation that is used for development (on which environment the dependencies are already installed, thus missing specification of dependencies go unnoticed).
630
631Manually testing all these aspects can be boring and prone to mistakes.  To make the life of egg authors easier, we have a tool to test initial versions of eggs: [[/egg/test-new-egg|test-new-egg]].  Using it is very easy: just install it (via chicken-install) and provide the URI for the .release-info file as argument to it:
632
633  $ test-new-egg <egg name> <.release-info file's URI>
634
Note: See TracBrowser for help on using the repository browser.