[racket] Worried about the new package manager not storing each version of a package

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