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

I think the right approach to running multiple Racket applications at once
that all rely on packages that might conflict is to use multiple
installations of Racket. Then you can install packages installation-wide
and not have them conflict.

This is, I think, quite similar to the way people deploy Ruby applications
with something like rvm or Python applications with pyenv.

Sam
On Aug 27, 2013 2:38 AM, "Lawrence Woodman" <lwoodman at vlifesystems.com>
wrote:

> 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/<https://github.com/carl-eastlund/mischief/tarball/>     fe7119517a4dcd3f5c509735a7b5a5
>> **664151c14f
>>
>> 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<http://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 <http://lists.racket-lang.org/users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130827/6fc94bec/attachment.html>