On 08/26/13 14:27, Matthew Flatt wrote:
A _package name_ is something like "mischief", which you use for
installing and declaring dependencies. A _package implementation_ is
something that you download from, say,
https://github.com/carl-eastlund/mischief/tarball/
fe7119517a4dcd3f5c509735a7b5a5664151c14f
Note that a package implementation in this sense corresponds to
specific revision of a pile of code, such as a particular commit in a
git repository. The package manager includes the concepts of a "package
source" and a "checksum", which together tell you how to get a package
implementation. (That implementation may have its own version number,
but such a version number is in principle orthogonal to the package
implementation's checksum.)
The mapping from a package name to a package implementation is provided
by a "catalog". PLT provides a catalog server at pkg.racket-lang.org,
but you can make your own catalog (as a server or on a local
filesystem), and so you can precisely control the mapping from package
names to packages.
Furthermore, we've added tools to `raco pkg' to make it easier to
manage catalogs. For example, if you want to take a snapshot of the
current pkg.racket-lang.org and use that from now on (so that the
mapping from package names to packages doesn't change), use these
commands:
raco pkg catalog-copyhttps://pkg.racket-lang.org /full/path/to/catalog/
raco pkg config --set catalogsfile:///full/path/to/catalog/
You can modify the files generated at "/full/path/to/catalog/" by hand
in a fairly obvious way. Or you can upload the directory to a
file-serving HTTP site and point installations to the uploaded
directory as the catalog. There's also an option to use an SQLite
database as the format for a catalog, which is a better option if you
want to modify the catalog programmatically via `pkg/db', but an SQLite
database is less easy to use from a file-serving HTTP site.
In particular, I can imagine having a project whose source code
includes a package catalog. To upgrade a particular package, I'd change
the catalog and `raco pkg update'. When I commit a particular revision
of the source code to a git repository, the package catalog is saved;
then, I can roll pack the project (including its references to specific
package implementations) to any previous version with its associated
package implementation via a `git checkout' (or whatever) plus `raco
pkg update'. Working this way, the package catalog acts a lot like git
submodules.
This would all rely on being able to access previous revisions to point
the catalogue to.
Not too big a problem if accessing a package through github, but how
would you do this
if the source is just a zip file, unless the package author is going to
host each and every
revision that they made with a unique name? Yes, you could download
these revisions
and point to them locally. However, if you wanted to distribute your
packages you
would then also have to be prepared to distribute revisions of other
authors' packages.
I can create stability for me by backing up revisions of packages that
work with an
application and pointing an application's package catalogue to those
revisions. However,
this would mean running package update before each run of a racket
application. It would
also mean that to develop the application with multiple contributors
that I would have to have
a method to distribute other authors' package revisions.
With all this package updating, what happens if I want to run two racket
applications at
the same time that rely on different conflicting releases of a package?
This all seems like a real pain and incredibly brittle and frustrating.
One little slip, such as
forgetting to backup the packages before an update and you could break
an application
or package with potentially no way of recovering other then
re-implementing the functionality
of an updated package that you were relying on.
Everyday that I use Racket I love it more and more, but I'm scared to
invest money building and
marketing an application, written in Racket, to be used commercially
while these problems remain.
I want to build my business, like my house, on rock and not sand.
I'm sure that I am not and will not be the only person who worries about
this. Racket has some
fantastic contributors with a great academic background, but
occasionally it may be useful to hear
the concerns of businesses wishing to invest in Racket and develop with it.
Thanks
Lorry
--
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry,
CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com
____________________
Racket Users list:
http://lists.racket-lang.org/users
