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

On 08/26/13 13:36, Jay McCarthy wrote:
> On Mon, Aug 26, 2013 at 12:57 AM, Lawrence Woodman
> <lwoodman at vlifesystems.com> wrote:
>> I have been really impressed with Racket after using it for a month, but am
>> worried about the move away from a central repository for storing each
>> version of a package.  I can see the advantage and simplicity of the new
>> system, but worry that relying on package creators to manage their packages
>> correctly could be creating a house of cards and see several problems with
>> this:
>>
>>      i.  If a package owner releases a change that breaks the API
>> (intentionally or
>>          unintentionally), then the packages and applications that depend on
>> it will no
>>          longer function and will be unable to do anything about it. If each
>> package
>>          version was stored then anything that depended on it could specify
>> that it
>>          needs a previous version to work.
> The users can do something. They can save their old version before
> they upgrade and not continue if there is a problem. The package
> system definitely supports "trials" like this, because it's easy to
> locate the files you downloaded for the package. I don't recommend
> blind updates in any package system.

It seems like a lot of manual intervention, compared to a package just being
able to say that it depends on a certain version or versions of a 
package to work.
In this scenario, if I understand what you mean, a user would have to 
save their current
versions of packages before updating and then test each and every piece 
of software
that depended on the updated packages to see if they break, before 
accepting the updates.

The above is a big enough pain, when developing something in isolation, 
but if developing with multiple authors, as many open source projects 
do, then each would have to restrict their updates. They would then have 
to make a decision with future software using those packages as to 
whether to stick to the old verions of those packages and hence not be 
able to take advantage of any improvements, or break previous software.

What happens if a user has an application they are quite happy using, 
but want to use another application that would mean installing an 
updated package that would break the first application?

Compare this to Ruby gems, where each version of a gem is kept locally 
and if a another gem
or application requires specific versions then they can easily specify 
this.  Therefore if an update
downloads a gem that turns out to not be compatible then you can easily 
specify for anything
that breaks, not to use the version of the gem.

>>      ii. If the owner of a package stops hosting it then the scenario above
>> would again
>>         happen.
> If a developer does not want to maintain or host a package, then I do
> not feel we have the right to obligate them to do so or to allow us
> to. If they license their code in a compatible way, however, a
> passionate user could take it over.


It's surprising that you feel this way, particularly considering the 
number of packages on PLaneT that haven't been touched for years. People 
move away all the time from software they have written, but if licensed 
in an agreeable way continues to be used quite happily.

A package could be used by other packages in a chain several levels 
deep, if deleted it could have a domino effect on all the other packages 
that rely on it in that chain.


>>      iii.  When used with github, most people will point to their master
>> branch, which
>>           if being used collaboratively could be quite unstable.  The users
>> of the package
>>           probably won't have any knowledge of this and will only find out
>> when their
>>           applications or packages keep breaking.  The easiest way of
>> thinking about this
>>           is if we were all forced to work with the latest commits from the
>> master branch
>>           of Racket and there were no versioned releases.
> I'm not sure what "most people" will do and I don't think I can
> control it. People can point to master or they can use a different
> "stable" branch. It's their choice and your choice as a user whether
> you want to patronize packages that seem unstable.


After a quick scrape of the packages directory I only found 4 packages 
using a github source that weren't pointing to the master branch:
     irc, mischief, websocket and xdgbasedir

It is true that we can't control what other people do and this is why I 
feel this is important.  Whatever peoples' future intentions for a 
package, once a release has been made and we are satisfied enough to use 
it, then we should be able to at least rely on that release.  It seems 
like asking too much to expect users to not only assess a package for 
stability, but also assess each dependency and assess each of their 
dependencies in a chain until you have no more dependencies to check.


Lorry