Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

At Sun, 9 Dec 2012 08:14:28 -0500, Sam Tobin-Hochstadt wrote:
> On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy  wrote:
> > My idea of "raco pkg migrate" is just to get a list of the packages that you
> > have installed and re-install them. 

Yes, that's what I had in mind.

(It may make sense to add an argument to `raco pkg list' to pick a
version or to specify "the most recent previous version", which could
be used by both `raco pkg migrate' and a graphical variant.)


> Second, I think an upgradeable installation, replacing the `bin` and
> `collects` directories, so that migration of packages isn't needed
> would work better -- that's more like how those of us who use git
> work, and I think we're mostly happy with that.

I think this works for us only because we're experts and we know how to
patch up the problems. I would never recommend working with a git
checkout to a student or new user of Racket. I would never recommend
installing a new version on top of an existing version (while I think
that installing two different versions to different directories should
just work).

> But even with `migrate`, I think the behavior *needs* to be be 'copy
> the files, call `setup`'.

When was the last time you patched part of your Linux installation and
expected the patch to be in place after an upgrade? I know there are
people who do that, but I don't think those people use the most popular
and "friendly" distributions, which try to keep installation and
maintenance simple.


The default has to be the thing that just works.

The thing that is best for experienced developers can be one step away
from the default --- since experienced developers are, by definition,
people who can deal with taking a step away from the default.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Sun, Dec 9, 2012 at 6:14 AM, Sam Tobin-Hochstadt wrote:

> On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy 
> wrote:
> > On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay  wrote:
> >>
> >> 30 minutes ago, Jay McCarthy wrote:
> >> > On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay 
> wrote:
> >> >
> >> > > One other thing that I think is important in a migration path is
> >> > > keeping any modification made to the source of the packages that
> >> > are
> >> > > already installed.
> >> >
> >> > Yeah -- and IIUC, the difference between the two installations is
> >> > where the packages get installed is where the compiled files are,
> so
> >> > the sources are the same.  At least I *hope* that that's how it
> is,
> >> > otherwise it's back to the whole planet "cache" things, which IMO
> >> > was
> >> > a major mistake.
> >> >
> >> > They are in the same place. However, I thought the whole premise of
> >> > this proposed behavior is that the package won't work in the new
> >> > version of Racket, so certainly the package system can't be
> >> > responsible for doing a merge your local changes and whatever the
> >> > updated version of the package needs.
> >>
> >> I'm not following that -- the compiled files and the sources are in
> >> the same place?  If so then it makes the whole migration thing kind of
> >> impossible with local changes, no?  (And I wasn't thinking about
> >> merging, just reusing the same sources.)
> >
> >
> > :) Now I'm not following you.
> >
> > If you have a package named P that has a module A/B/C.rkt then on your
> disk
> > is in:
> >
> > ~/.racket/$version/pkgs/P/A/B/C.rkt
> >
> > with its compiled code in:
> >
> > ~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo
> >
> > My idea of "raco pkg migrate" is just to get a list of the packages that
> you
> > have installed and re-install them. I think if we assume that Racket
> > versions will break package P then those same problems will prevent you
> from
> > keeping local changes; especially if the package system isn't responsible
> > for running merge, which it clearly shouldn't be. (Now, I don't think
> that's
> > a reasonable assumption, i.e. I think version-less should be the default,
> > but I've clearly been out-voted.)
>
> First, I still agree with you about version-less being the default.
>
> Second, I think an upgradeable installation, replacing the `bin` and
> `collects` directories, so that migration of packages isn't needed
> would work better -- that's more like how those of us who use git
> work, and I think we're mostly happy with that.
>
> But even with `migrate`, I think the behavior *needs* to be be 'copy
> the files, call `setup`'.  Otherwise it won't work on a system without
> the internet, for example. My impression about the reasons for
> version-specific packages and 'migrate' are that when upgrading, just
> keeping the same code will potentially error, and so users shouldn't
> *automatically* keep the same code.  But I thought of `migrate` as
> 'make it seem like those packages were installed for this new
> installation'.


I don't see any difference between what you're proposing and version-less
being default where you type "raco setup" (or something does it for you)
after install. I think that Matthew believes that this won't work because a
user may need to get new source code for a package when the Racket version
changes, but maybe I've misunderstood his worry.

Jay


-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy  wrote:
> On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay  wrote:
>>
>> 30 minutes ago, Jay McCarthy wrote:
>> > On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay  wrote:
>> >
>> > > One other thing that I think is important in a migration path is
>> > > keeping any modification made to the source of the packages that
>> > are
>> > > already installed.
>> >
>> > Yeah -- and IIUC, the difference between the two installations is
>> > where the packages get installed is where the compiled files are, so
>> > the sources are the same.  At least I *hope* that that's how it is,
>> > otherwise it's back to the whole planet "cache" things, which IMO
>> > was
>> > a major mistake.
>> >
>> > They are in the same place. However, I thought the whole premise of
>> > this proposed behavior is that the package won't work in the new
>> > version of Racket, so certainly the package system can't be
>> > responsible for doing a merge your local changes and whatever the
>> > updated version of the package needs.
>>
>> I'm not following that -- the compiled files and the sources are in
>> the same place?  If so then it makes the whole migration thing kind of
>> impossible with local changes, no?  (And I wasn't thinking about
>> merging, just reusing the same sources.)
>
>
> :) Now I'm not following you.
>
> If you have a package named P that has a module A/B/C.rkt then on your disk
> is in:
>
> ~/.racket/$version/pkgs/P/A/B/C.rkt
>
> with its compiled code in:
>
> ~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo
>
> My idea of "raco pkg migrate" is just to get a list of the packages that you
> have installed and re-install them. I think if we assume that Racket
> versions will break package P then those same problems will prevent you from
> keeping local changes; especially if the package system isn't responsible
> for running merge, which it clearly shouldn't be. (Now, I don't think that's
> a reasonable assumption, i.e. I think version-less should be the default,
> but I've clearly been out-voted.)

First, I still agree with you about version-less being the default.

Second, I think an upgradeable installation, replacing the `bin` and
`collects` directories, so that migration of packages isn't needed
would work better -- that's more like how those of us who use git
work, and I think we're mostly happy with that.

But even with `migrate`, I think the behavior *needs* to be be 'copy
the files, call `setup`'.  Otherwise it won't work on a system without
the internet, for example. My impression about the reasons for
version-specific packages and 'migrate' are that when upgrading, just
keeping the same code will potentially error, and so users shouldn't
*automatically* keep the same code.  But I thought of `migrate` as
'make it seem like those packages were installed for this new
installation'.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay  wrote:

> 30 minutes ago, Jay McCarthy wrote:
> > On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay  wrote:
> >
> > > One other thing that I think is important in a migration path is
> > > keeping any modification made to the source of the packages that
> are
> > > already installed.
> >
> > Yeah -- and IIUC, the difference between the two installations is
> > where the packages get installed is where the compiled files are, so
> > the sources are the same.  At least I *hope* that that's how it is,
> > otherwise it's back to the whole planet "cache" things, which IMO was
> > a major mistake.
> >
> > They are in the same place. However, I thought the whole premise of
> > this proposed behavior is that the package won't work in the new
> > version of Racket, so certainly the package system can't be
> > responsible for doing a merge your local changes and whatever the
> > updated version of the package needs.
>
> I'm not following that -- the compiled files and the sources are in
> the same place?  If so then it makes the whole migration thing kind of
> impossible with local changes, no?  (And I wasn't thinking about
> merging, just reusing the same sources.)


:) Now I'm not following you.

If you have a package named P that has a module A/B/C.rkt then on your disk
is in:

~/.racket/$version/pkgs/P/A/B/C.rkt

with its compiled code in:

~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo

My idea of "raco pkg migrate" is just to get a list of the packages that
you have installed and re-install them. I think if we assume that Racket
versions will break package P then those same problems will prevent you
from keeping local changes; especially if the package system isn't
responsible for running merge, which it clearly shouldn't be. (Now, I don't
think that's a reasonable assumption, i.e. I think version-less should be
the default, but I've clearly been out-voted.)

Jay

-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

30 minutes ago, Jay McCarthy wrote:
> On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay  wrote:
> 
> > One other thing that I think is important in a migration path is
> > keeping any modification made to the source of the packages that are
> > already installed.
>
> Yeah -- and IIUC, the difference between the two installations is
> where the packages get installed is where the compiled files are, so
> the sources are the same.  At least I *hope* that that's how it is,
> otherwise it's back to the whole planet "cache" things, which IMO was
> a major mistake.
> 
> They are in the same place. However, I thought the whole premise of
> this proposed behavior is that the package won't work in the new
> version of Racket, so certainly the package system can't be
> responsible for doing a merge your local changes and whatever the
> updated version of the package needs.

I'm not following that -- the compiled files and the sources are in
the same place?  If so then it makes the whole migration thing kind of
impossible with local changes, no?  (And I wasn't thinking about
merging, just reusing the same sources.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay  wrote:

> > One other thing that I think is important in a migration path is
> > keeping any modification made to the source of the packages that are
> > already installed.
>
> Yeah -- and IIUC, the difference between the two installations is
> where the packages get installed is where the compiled files are, so
> the sources are the same.  At least I *hope* that that's how it is,
> otherwise it's back to the whole planet "cache" things, which IMO was
> a major mistake.


They are in the same place. However, I thought the whole premise of this
proposed behavior is that the package won't work in the new version of
Racket, so certainly the package system can't be responsible for doing a
merge your local changes and whatever the updated version of the package
needs.

Jay

-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

Just now, Sam Tobin-Hochstadt wrote:
> On Dec 8, 2012 10:14 PM, "Eli Barzilay"  wrote:
> >
> > I think that this is exactly what Matthew was talking about.  One
> > tricky bit here is to know which packages were installed for which
> > level.  If *you* installed some packages, then the next time you
> > *run* (not install) an updated racket version you'd be asked if
> > you want to do the migration.  But if some package was installed
> > as part of the racket tree (not user specific) then the same
> > question would apply when a new version gets installed.
> 
> Why would this wait for the first run for any packages?

As usual, think about a lab with a central sysadmin-made racket
installation.  It's impossible to crawl over all users and change
stuff in their home directory when the sysadmin upgrades the
installation.

Now carry this over to OSX and Windows, and it's the same thing.  (And
even Windows is moving toward a more strict separation between the
administrator and plain users.)  The thing that makes it somewhat
easier there is that the interaction tends to be a single user that
plays both roles.  So either the user installed some packages "for
everyone" and the upgrade will update those at installation time, or
the user installed things for himself, and the upgrade will happen
when the new version runs -- usually just after the new installation.


> One other thing that I think is important in a migration path is
> keeping any modification made to the source of the packages that are
> already installed.

Yeah -- and IIUC, the difference between the two installations is
where the packages get installed is where the compiled files are, so
the sources are the same.  At least I *hope* that that's how it is,
otherwise it's back to the whole planet "cache" things, which IMO was
a major mistake.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Dec 8, 2012 10:14 PM, "Eli Barzilay"  wrote:
>
> On Wednesday, Sam Tobin-Hochstadt wrote:
> >
> > Given that context, maybe the right thing here is (a) installation-
> > specific packages by default and (b) a way to *upgrade* an existing
> > installation when installing.  That might be as simple as
> > automatically running 'raco pkg migrate', but I think making it part
> > of the installation step would make life easier for people, and
> > perhaps an upgrade could avoid duplicating files.
>
> I think that this is exactly what Matthew was talking about.  One
> tricky bit here is to know which packages were installed for which
> level.  If *you* installed some packages, then the next time you *run*
> (not install) an updated racket version you'd be asked if you want to
> do the migration.  But if some package was installed as part of the
> racket tree (not user specific) then the same question would apply
> when a new version gets installed.

Why would this wait for the first run for any packages?

One other thing that I think is important in a migration path is keeping
any modification made to the source of the packages that are already
installed.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

On Wednesday, Sam Tobin-Hochstadt wrote:
> 
> Given that context, maybe the right thing here is (a) installation-
> specific packages by default and (b) a way to *upgrade* an existing
> installation when installing.  That might be as simple as
> automatically running 'raco pkg migrate', but I think making it part
> of the installation step would make life easier for people, and
> perhaps an upgrade could avoid duplicating files.

I think that this is exactly what Matthew was talking about.  One
tricky bit here is to know which packages were installed for which
level.  If *you* installed some packages, then the next time you *run*
(not install) an updated racket version you'd be asked if you want to
do the migration.  But if some package was installed as part of the
racket tree (not user specific) then the same question would apply
when a new version gets installed.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Laurent]

> Given that context, maybe the right thing here is (a)
> installation-specific packages by default and (b) a way to *upgrade*
> an existing installation when installing.  That might be as simple as
> automatically running 'raco pkg migrate', but I think making it part
> of the installation step would make life easier for people, and
> perhaps an upgrade could avoid duplicating files.
>

I second that.
Being a more "normal" user that most of you, my installation only usually
has one version of Racket (in general one of the last nightlies).
If you go for the upgrade option, it would be really appreciated if, during
installation or on the first run of DrRacket (preferably the former,
because of DrRacket Tools), I'm asked whether I want to keep/migrate my
packages for the new version.
It's currently quite annoying to have to do all this reinstalling by hand.

Laurent
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Sun, Dec 2, 2012 at 11:11 AM, Matthew Flatt  wrote:
> At Sun, 2 Dec 2012 10:55:01 -0500, Sam Tobin-Hochstadt wrote:
>> I have mostly the opposite impression of `raco link`.  I like the
>> default behavior, but that may be a result of my use of a set of
>> scripts [1] for managing Racket installations that makes basically
>> everything into installation-specific packages.
>
> It sounds like you're advocating something that you haven't tried, and
> you wanted installation-specific links, anyway.

I think what's going on here is that we both work in the following style:
 - a single primary installation from git, upgraded across versions,
with frequent
   version changes, which we want to keep the same set of packages on upgrade
 - several separate installs from nightly builds or releases, used primarily for
   testing or for running some single program that remains stable

However, we're imagining that most Racket users will use the following style:
 - a single installation from a release, which is probably removed
when upgrading
   to a new installation of a new version

And we're both trying to capture what we like about how we want to
work for users with a different style.  I see the important feature of
my work style as 'packages stay installed when I pull from git', and
you see 'when I use a different version, I don't get spurious packages
that I didn't wand and don't work'.

Does that seem like a fair summary?

Given that context, maybe the right thing here is (a)
installation-specific packages by default and (b) a way to *upgrade*
an existing installation when installing.  That might be as simple as
automatically running 'raco pkg migrate', but I think making it part
of the installation step would make life easier for people, and
perhaps an upgrade could avoid duplicating files.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Danny Yoo]

> Exactly. That student is going to get an error message when DrRacket
> starts up saying that the handin tool is broken. They complain to
> someone, and so on.
>
>
Or, even worse, the student can get the error message at Check Syntax time,
after which because it's an internal error, DrRacket goes unresponsive and
the user can't even save their program anymore.  (I've had this happen a
few times, and it's one of the worse case scenarios I've run into.)
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

At Sun, 2 Dec 2012 10:55:01 -0500, Sam Tobin-Hochstadt wrote:
> I have mostly the opposite impression of `raco link`.  I like the
> default behavior, but that may be a result of my use of a set of
> scripts [1] for managing Racket installations that makes basically
> everything into installation-specific packages.

It sounds like you're advocating something that you haven't tried, and
you wanted installation-specific links, anyway.

If there's still some reason that environment-variable scripts are the
way to go as far as packages are concerned, then let's add an
environment variable that changes the default for package installation
and affects only people who know how to deal with it.

> One additional issue with version-specific installs that I just
> thought of -- imagine a student installing a course package on a lab
> computer, and then Racket being upgraded during the semester.

Exactly. That student is going to get an error message when DrRacket
starts up saying that the handin tool is broken. They complain to
someone, and so on.

It would be much better for the handin tool (for the class they aren't
taking anymore) to just be gone until they specifically ask for it back
through a migration tool. Or they just shrug and re-install, but that's
more obvious and doesn't involve bugging a teacher or admin.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Sun, Dec 2, 2012 at 10:38 AM, Matthew Flatt  wrote:
> Who here has tried using `raco link' for development?

I use `raco link` for all of my development -- once `raco link` was
released, I basically gave up on Planet1 and used `raco link` for
everything.

> The default mode is user-specific but not version-specific, and I've
> found that default to be inconvenient. Usually, it turns out, I want an
> installation-specific link, because I want it linked only for my
> development version of Racket. When I get to the point that I do want
> to use a different Racket version, it's a pain to juggle the links or
> make a copy for different version. I look forward to using packages,
> installation-specific links, and version-specific installs that are
> taken as snapshots of the git repo.

I have mostly the opposite impression of `raco link`.  I like the
default behavior, but that may be a result of my use of a set of
scripts [1] for managing Racket installations that makes basically
everything into installation-specific packages.

One additional issue with version-specific installs that I just
thought of -- imagine a student installing a course package on a lab
computer, and then Racket being upgraded during the semester.

[1] https://github.com/takikawa/racket-dev-goodies
--
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

Who here has tried using `raco link' for development?

The default mode is user-specific but not version-specific, and I've
found that default to be inconvenient. Usually, it turns out, I want an
installation-specific link, because I want it linked only for my
development version of Racket. When I get to the point that I do want
to use a different Racket version, it's a pain to juggle the links or
make a copy for different version. I look forward to using packages,
installation-specific links, and version-specific installs that are
taken as snapshots of the git repo.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

At Sun, 2 Dec 2012 10:15:56 -0500, Sam Tobin-Hochstadt wrote:
>  - Developer convenience is important, and most of us use git HEAD,
> whose versions change quite rapidly.

Consider installing packages to work with your git HEAD checkout as
installation-specific packages. That way, there's no version issue ---
and when you want to check Racket's behavior in the current release,
your git HEAD build doesn't interfere with the release.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Sat, Dec 1, 2012 at 10:56 AM, Jay McCarthy  wrote:
> On Fri, Nov 30, 2012 at 7:09 PM, Matthew Flatt  wrote:
>> Version-specific installation
>> -
>> Not to speak too much on Jay's behalf, but I think he isn't convinced
>> that the new default is right. If `--shared' is the default, then a
>> `raco pkg update' could be enough to get all your installed packages
>> working with a new version. If installation is instead
>> version-specific, then you have to reinstall every package that you use
>> whenever you upgrade.
>>
>> I think that if installation is all-version by default, then users who
>> are going to end up with bad configurations that they have trouble
>> repairing. A better way to deal with upgrades would be something like
>> `raco pkg migrate'.
>>
>> If we decide that version-specific is the right default to keep, and if
>> some would still like a more convenient way to manage all-version
>> packages, we could add an environment variable that makes `--shared'
>> the default.
>
> Something that bothers me a lot of P1 is that when I install an
> upgrade, I lose all my packages. This means that the documentation
> search suddenly starts returning different things, so I forget about
> which packages I had installed at all. I only discover this when I go
> to write something and have a long install and download process. Or,
> when I run a script I wrote a long time ago and it doesn't return
> instantly, but spawns an install.
>
> I'm much less worried about Racket versions breaking installed
> packages than Matthew. I don't think it is that common for core
> changes to break things and when it does happen, P2 is designed to
> easily allow you to upgrade all your packages to the latest versions,
> something that was very inconvenient with P1. I.e. you can do "raco
> pkg update --all", which isn't possible with P1.

I strongly agree with Jay here.  A few additional reasons, besides
what he explained:

 - The explanation "that package doesn't work with the latest Racket,
you need to update it" is easier for people to understand than "you
don't have that package installed, unless you do in which case you
should migrate it to your current version".  This is helped by the
fact that most other languages that I know of have all-version
installation.
 - Developer convenience is important, and most of us use git HEAD,
whose versions change quite rapidly.  Now following the version number
is very important, otherwise all your software will break.
 - Once many of the current collects move to packages, there will be
many fewer opportunities to break the behavior of the "core", so the
problems Matthew worries about will be less severe, and the problems
Jay and I worry about may be more severe.
 - Version-specific installation does not work well with
package-specific installation, which is something I hope we can add as
an option in the future.
 - One drawback of version-specific installation in Planet1 that I
experienced was that fixing an installed Planet package by editing the
source broke entirely when switching to a new version.  Relatedly,
version-specific install almost requires putting the installations in
an out-of-the-way directory, making finding and editing source more
difficult.

--
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

Yes, what you describe is what we imagine "migrate" will do.

Jay

On Sat, Dec 1, 2012 at 4:10 PM, Eli Barzilay  wrote:
> Yesterday, Matthew Flatt wrote:
>> I've been working with Jay on a few more changes:
>>
>> Specifying metadata
>> ---
>>
>> "METADATA.rktd" is being replaced with "info.rkt", which is written in
>> the `setup/infotab' language as usual.
>>
>> Define `deps' for dependencies, like this:
>>
>>#lang setup/infotab
>>(define deps (list _package-source ...))
>>
>> For a short transition period (maybe a week?), `raco pkg' will continue
>> to recognize "METADATA.rktd".
>>
>>
>> Version-specific installation
>> -
>>
>> Package installation is now both user-specific and version-specific
>> by default. The options are
>>
>>  * installation-specific
>>
>>  * user-specific and version-specific (the new default)
>>
>>  * user-specific and all-version (the old default)
>>
>> Use the `--shared' or `-s' flag to get the old all-version behavior.
>> Any previously installed user-specific packages that you have are still
>> in `--shared' mode.
>>
>> Not to speak too much on Jay's behalf, but I think he isn't convinced
>> that the new default is right. If `--shared' is the default, then a
>> `raco pkg update' could be enough to get all your installed packages
>> working with a new version. If installation is instead
>> version-specific, then you have to reinstall every package that you use
>> whenever you upgrade.
>>
>> I think that if installation is all-version by default, then users
>> who are going to end up with bad configurations that they have
>> trouble repairing. A better way to deal with upgrades would be
>> something like `raco pkg migrate'.
>
> Just to see if I get the trade-offs right: all-version installs have
> the advantage of not re-installing things, and the disadvantage of
> breaking often (for some value of "often")?
>
> If so, then something that I think is getting popular is keeping a
> (global) list of all explicitly installed packages, and then the
> version-specific installs get much easier to deal with because it's
> easy to crawl over the explicit names and re-install name.  Having
> this only for explicit names meams that I don't need to reinstall old
> stuff that was installed only for some other package.
>
> (But perhaps this is what you talk about with that `migrate' command.
> If so, then this is just a verbose +1.)
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev



--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

Yesterday, Matthew Flatt wrote:
> I've been working with Jay on a few more changes:
> 
> Specifying metadata
> ---
> 
> "METADATA.rktd" is being replaced with "info.rkt", which is written in
> the `setup/infotab' language as usual.
> 
> Define `deps' for dependencies, like this:
> 
>#lang setup/infotab
>(define deps (list _package-source ...))
> 
> For a short transition period (maybe a week?), `raco pkg' will continue
> to recognize "METADATA.rktd".
> 
> 
> Version-specific installation
> -
> 
> Package installation is now both user-specific and version-specific
> by default. The options are
> 
>  * installation-specific
> 
>  * user-specific and version-specific (the new default)
> 
>  * user-specific and all-version (the old default)
> 
> Use the `--shared' or `-s' flag to get the old all-version behavior.
> Any previously installed user-specific packages that you have are still
> in `--shared' mode.
> 
> Not to speak too much on Jay's behalf, but I think he isn't convinced
> that the new default is right. If `--shared' is the default, then a
> `raco pkg update' could be enough to get all your installed packages
> working with a new version. If installation is instead
> version-specific, then you have to reinstall every package that you use
> whenever you upgrade.
> 
> I think that if installation is all-version by default, then users
> who are going to end up with bad configurations that they have
> trouble repairing. A better way to deal with upgrades would be
> something like `raco pkg migrate'.

Just to see if I get the trade-offs right: all-version installs have
the advantage of not re-installing things, and the disadvantage of
breaking often (for some value of "often")?

If so, then something that I think is getting popular is keeping a
(global) list of all explicitly installed packages, and then the
version-specific installs get much easier to deal with because it's
easy to crawl over the explicit names and re-install name.  Having
this only for explicit names meams that I don't need to reinstall old
stuff that was installed only for some other package.

(But perhaps this is what you talk about with that `migrate' command.
If so, then this is just a verbose +1.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Fri, Nov 30, 2012 at 7:09 PM, Matthew Flatt  wrote:
> Version-specific installation
> -
> Not to speak too much on Jay's behalf, but I think he isn't convinced
> that the new default is right. If `--shared' is the default, then a
> `raco pkg update' could be enough to get all your installed packages
> working with a new version. If installation is instead
> version-specific, then you have to reinstall every package that you use
> whenever you upgrade.
>
> I think that if installation is all-version by default, then users who
> are going to end up with bad configurations that they have trouble
> repairing. A better way to deal with upgrades would be something like
> `raco pkg migrate'.
>
> If we decide that version-specific is the right default to keep, and if
> some would still like a more convenient way to manage all-version
> packages, we could add an environment variable that makes `--shared'
> the default.

Something that bothers me a lot of P1 is that when I install an
upgrade, I lose all my packages. This means that the documentation
search suddenly starts returning different things, so I forget about
which packages I had installed at all. I only discover this when I go
to write something and have a long install and download process. Or,
when I run a script I wrote a long time ago and it doesn't return
instantly, but spawns an install.

I'm much less worried about Racket versions breaking installed
packages than Matthew. I don't think it is that common for core
changes to break things and when it does happen, P2 is designed to
easily allow you to upgrade all your packages to the latest versions,
something that was very inconvenient with P1. I.e. you can do "raco
pkg update --all", which isn't possible with P1.

Jay

--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

I've been working with Jay on a few more changes:

Specifying metadata
---

"METADATA.rktd" is being replaced with "info.rkt", which is written in
the `setup/infotab' language as usual.

Define `deps' for dependencies, like this:

   #lang setup/infotab
   (define deps (list _package-source ...))

For a short transition period (maybe a week?), `raco pkg' will continue
to recognize "METADATA.rktd".


Version-specific installation
-

Package installation is now both user-specific and version-specific
by default. The options are

 * installation-specific

 * user-specific and version-specific (the new default)

 * user-specific and all-version (the old default)

Use the `--shared' or `-s' flag to get the old all-version behavior.
Any previously installed user-specific packages that you have are still
in `--shared' mode.

Not to speak too much on Jay's behalf, but I think he isn't convinced
that the new default is right. If `--shared' is the default, then a
`raco pkg update' could be enough to get all your installed packages
working with a new version. If installation is instead
version-specific, then you have to reinstall every package that you use
whenever you upgrade.

I think that if installation is all-version by default, then users who
are going to end up with bad configurations that they have trouble
repairing. A better way to deal with upgrades would be something like
`raco pkg migrate'.

If we decide that version-specific is the right default to keep, and if
some would still like a more convenient way to manage all-version
packages, we could add an environment variable that makes `--shared'
the default.


Setup after installation


Previously, `raco pkg install' would run the equivalent of `raco setup'
with no arguments after installing packages. Now, `raco pkg install'
runs the equivalent of `raco setup  ...', where the
s are all the ones represented installed packages, plus
"scribblings/main/user" and/or "scribblings/main".

To control the set of s added to `raco setup' for a
package, define `setup-collects' in the package's "info.rkt". Use 'all
to get the old behavior (i.e., global setup) back.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

At Fri, 30 Nov 2012 09:00:55 -0500, Eli Barzilay wrote:
> Yesterday, Asumu Takikawa wrote:
> > On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote:
> > >
> > >  raco pkg install fish-tank/
> > 
> > This is nice, I've been confused by the old behavior before.
> 
> I don't think that this is a good idea -- since it's a hook onto a
> syntax of directory names which conflicts with the common convention
> that "dir/" is the same as "dir".  One random example where this can
> be a problem is zsh directory completions -- with my setup (and this
> is a zsh feature that is used by many people) if I have a "fish-tank"
> directory and I type
> 
>   rack pkg install fish-
> 
> I get zsh to complete that and get
> 
>   rack pkg install fish-tank/
> 
> and if at this point I hit enter, zsh will *remove* that slash and
> then run the command:
> 
>   rack pkg install fish-tank
> 
> A slightly better convention for directory names is ./fish-tank -- but
> that convention is useful for cases where a string can be interpreted
> as either a local path or something else (like a flag) and I want to
> force the path interpretation.  IOW, it fits a mode of work where
> there is some dynamic interpretation based on the existence of a
> directory or a known package name, with a way to force the former.

Good point, and the "./" does prevent the path from being interpreted
as a package name. I'll change this.

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Robby Findler]

Yes, I think we're roughly on the same page. Printing is a bad idea
when installing, but logging seems fine and that is how drracket can
detect it should update the GUI to let people know that something is
being installed. And a command-line flag (that perhaps translates to
some setting on the namespace that is derived from a parameter) can
determine if installing packages is allowed or not.

I think all this is doable and I think we can get something that keeps
the "kiss" principle and make things "just work" in common situations
without sacrificing security or whathaveyou.

Robby

On Fri, Nov 30, 2012 at 10:38 AM, Eli Barzilay  wrote:
> Just now, Robby Findler wrote:
>> In DrR, it isn't looking at the log that tells you this, you get a
>> special bar appearing in the window. You don't have to do any extra
>> clicks or anything like that.
>
> (Yeah, take that as a generalized version of my "see the log"...)
>
>
>> That said, I don't mind if, when someone runs some planet2 code in
>> racket, outside drracket, that it raises an error saying "you need
>> to pass the --slow-me-down-but-automatically-download-missing-
>> packages flag, or just run this program in drracket".
>
> WRT the automatic download + install -- while it's obviously possible
> to do that, I think that because of such things it's generally bad to
> actually make "real code" depend on it.
>
> Here's what I mean: if you assume that there should always be some
> visible indication of a package being installed, there is not going to
> be some magical require that would always work silently, and that can
> interfere with actually running the code.  For example, you do some
>
>   (require (download-and-install-from-somewhere))
>
> and it might produce some output or it might not -- and the code that
> uses this might break if there's unexpected output.
>
> But such a functionality is obviously useful -- so how about including
> it only for interactive purposes, which means that you can use it in
> your blogged code since you know that the extra output is not
> interfering with your code.  If OTOH you post some script for people
> to run, then you don't use that and instead tell people that they
> should install the other needed package, and later just pack your own
> code as a package.
>
> 
>
> This might lead to an interesting direction.  Since it's not boring,
> it might not be a good idea, but still I think that it looks
> promising...
>
> Imagine that there was some meta syntax for required packages (I'll
> use emacs-like hackish-isms):
>
>   #lang racket
>   ;; *** Requires: some-package ***
>   ... code ...
>
> This idea can be taken further to add more package-like features,
> eventually like
>
>   #lang racket
>   ;; *** Package: name-for-this-code-as-a-package ***
>   ;; *** Requires: some-package ***
>   ... code ...
>
> which can eventually make it possible to treat a single file as a
> package.
>
> The nice thing that should be obvious now is that there's no need for
> such hacks, since that require line is serving the same purpose.
> Except that to really make it possible to do this effectively, you
> need to be able to know the package information separately for the
> code -- and submodules look like a perfect way to do that.  Just
> replace the hacks with something like:
>
>   #lang racket
>   (module pkg planet/pinfo   ; for "package info" or whatever
> (define package name-for-this-code-as-a-package)
> (requires some-package)
> (requires some-other-package and-another))
>   ... code ...
>
> Or drop the define for the shorter case.  And since this is still
> pretty verbose, it might be abstracted away in some macro.  (But I
> don't remember the dependency issues with such things, so it might not
> be doable as is.)
>
> I think that with something like that you can get everything that you
> want.  A plain run in drr can do the same thing when it sees that
> there's a package inforation.  Toplevel requires in the racket input
> can do the same, but just requiring this file from another will not do
> it which means that you can also use it this way without worrying
> about interfering with real runs.  And you can also have some new
> command like "raco pkg install-whatever-is-needed-for some-file.rkt"
> which would be like doing the toplevel require thing.
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Robby Findler]

In DrR, it isn't looking at the log that tells you this, you get a
special bar appearing in the window. You don't have to do any extra
clicks or anything like that.

That said, I don't mind if, when someone runs some planet2 code in
racket, outside drracket, that it raises an error saying "you need to
pass the --slow-me-down-but-automatically-download-missing-packages
flag, or just run this program in drracket".

Robby

On Fri, Nov 30, 2012 at 8:44 AM, Eli Barzilay  wrote:
> A few minutes ago, Robby Findler wrote:
>> I agree. Planet 1 currently does this.
>
> Only in drr, where you can see the log...  I've seen many people run
> some random code naively and complain that it does nothing besides
> spinning the cpu because some packages take a significant time to run.
>
>
>> On Friday, November 30, 2012, Eli Barzilay wrote:
>>
>> About three weeks ago, Robby Findler wrote:
>> > I would be unhappy, however, if we end up with a system where you
>> > have to grovel around in low-level places to get simple uses of
>> > uninstalled packages working. That is, I want to be able to put in a
>> > blog post or in a talk or somewhere a little program that depends on
>> > uninstalled libraries and, if I'm careful about keeping those
>> > libraries that the little file works with, then that file should
>> > Just Work for casual users who download drracket paste it in, and
>> > hit Run.
>>
>> IIUC, there is an API interface for installing packages, so it's
>> possible to write some expression that installs a package if it is not
>> installed.  The road from there to a require form that installs
>> something automatically if needed is probably not long, but I think
>> that one main thing that would make things better is if that results
>> in some visible output about the installation that is being done.
>> This avoids the problem of people who think that your random blogged
>> code is not doing anything.
>>
>> --
>>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
>> http://barzilay.org/   Maze is Life!
>>
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

About three weeks ago, Robby Findler wrote:
> I would be unhappy, however, if we end up with a system where you
> have to grovel around in low-level places to get simple uses of
> uninstalled packages working. That is, I want to be able to put in a
> blog post or in a talk or somewhere a little program that depends on
> uninstalled libraries and, if I'm careful about keeping those
> libraries that the little file works with, then that file should
> Just Work for casual users who download drracket paste it in, and
> hit Run.

IIUC, there is an API interface for installing packages, so it's
possible to write some expression that installs a package if it is not
installed.  The road from there to a require form that installs
something automatically if needed is probably not long, but I think
that one main thing that would make things better is if that results
in some visible output about the installation that is being done.
This avoids the problem of people who think that your random blogged
code is not doing anything.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

About three weeks ago, Jay McCarthy wrote:
> On Thu, Nov 8, 2012 at 1:48 PM, Eli Barzilay  wrote:
> > 20 minutes ago, Jay McCarthy wrote:
> >> I have no preference about this shed color. If others feel strongly,
> >> it can change.
> >
> > I do.  It would be better IMO to look at existing packagers and reuse
> > some of their conventions.  (I know that at least the chrome packages
> > have similar things, and I liked their design.)
> 
> I based the convention off CPAN with its META.yml file.

I think that CPAN is old enough to not be a good role model...


> > It should be possible to distribute the separate parts regardless
> > of where they are.  The thing is that with a single directory
> > management of code is much easier.  Eventually, many of the
> > collections in the current tree should move out into their own
> > repositories.
> 
> In any case, I've missed it and will make the change to the
> recommendations, although personally I like having separate
> directories like tests because it doesn't clutter my main code
> directory.

I think that a separate repository is a good thing to consider here:
you obviously need to clutter your repo with tests and documentation.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

A few minutes ago, Robby Findler wrote:
> I agree. Planet 1 currently does this.

Only in drr, where you can see the log...  I've seen many people run
some random code naively and complain that it does nothing besides
spinning the cpu because some packages take a significant time to run.


> On Friday, November 30, 2012, Eli Barzilay wrote:
> 
> About three weeks ago, Robby Findler wrote:
> > I would be unhappy, however, if we end up with a system where you
> > have to grovel around in low-level places to get simple uses of
> > uninstalled packages working. That is, I want to be able to put in a
> > blog post or in a talk or somewhere a little program that depends on
> > uninstalled libraries and, if I'm careful about keeping those
> > libraries that the little file works with, then that file should
> > Just Work for casual users who download drracket paste it in, and
> > hit Run.
>
> IIUC, there is an API interface for installing packages, so it's
> possible to write some expression that installs a package if it is not
> installed.  The road from there to a require form that installs
> something automatically if needed is probably not long, but I think
> that one main thing that would make things better is if that results
> in some visible output about the installation that is being done.
> This avoids the problem of people who think that your random blogged
> code is not doing anything.
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
> 

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

Yesterday, Asumu Takikawa wrote:
> On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote:
> >
> >  raco pkg install fish-tank/
> 
> This is nice, I've been confused by the old behavior before.

I don't think that this is a good idea -- since it's a hook onto a
syntax of directory names which conflicts with the common convention
that "dir/" is the same as "dir".  One random example where this can
be a problem is zsh directory completions -- with my setup (and this
is a zsh feature that is used by many people) if I have a "fish-tank"
directory and I type

  rack pkg install fish-

I get zsh to complete that and get

  rack pkg install fish-tank/

and if at this point I hit enter, zsh will *remove* that slash and
then run the command:

  rack pkg install fish-tank

A slightly better convention for directory names is ./fish-tank -- but
that convention is useful for cases where a string can be interpreted
as either a local path or something else (like a flag) and I want to
force the path interpretation.  IOW, it fits a mode of work where
there is some dynamic interpretation based on the existence of a
directory or a known package name, with a way to force the former.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

Just now, Robby Findler wrote:
> In DrR, it isn't looking at the log that tells you this, you get a
> special bar appearing in the window. You don't have to do any extra
> clicks or anything like that.

(Yeah, take that as a generalized version of my "see the log"...)


> That said, I don't mind if, when someone runs some planet2 code in
> racket, outside drracket, that it raises an error saying "you need
> to pass the --slow-me-down-but-automatically-download-missing-
> packages flag, or just run this program in drracket".

WRT the automatic download + install -- while it's obviously possible
to do that, I think that because of such things it's generally bad to
actually make "real code" depend on it.

Here's what I mean: if you assume that there should always be some
visible indication of a package being installed, there is not going to
be some magical require that would always work silently, and that can
interfere with actually running the code.  For example, you do some

  (require (download-and-install-from-somewhere))

and it might produce some output or it might not -- and the code that
uses this might break if there's unexpected output.

But such a functionality is obviously useful -- so how about including
it only for interactive purposes, which means that you can use it in
your blogged code since you know that the extra output is not
interfering with your code.  If OTOH you post some script for people
to run, then you don't use that and instead tell people that they
should install the other needed package, and later just pack your own
code as a package.



This might lead to an interesting direction.  Since it's not boring,
it might not be a good idea, but still I think that it looks
promising...

Imagine that there was some meta syntax for required packages (I'll
use emacs-like hackish-isms):

  #lang racket
  ;; *** Requires: some-package ***
  ... code ...

This idea can be taken further to add more package-like features,
eventually like

  #lang racket
  ;; *** Package: name-for-this-code-as-a-package ***
  ;; *** Requires: some-package ***
  ... code ...

which can eventually make it possible to treat a single file as a
package.

The nice thing that should be obvious now is that there's no need for
such hacks, since that require line is serving the same purpose.
Except that to really make it possible to do this effectively, you
need to be able to know the package information separately for the
code -- and submodules look like a perfect way to do that.  Just
replace the hacks with something like:

  #lang racket
  (module pkg planet/pinfo   ; for "package info" or whatever
(define package name-for-this-code-as-a-package)
(requires some-package)
(requires some-other-package and-another))
  ... code ...

Or drop the define for the shorter case.  And since this is still
pretty verbose, it might be abstracted away in some macro.  (But I
don't remember the dependency issues with such things, so it might not
be doable as is.)

I think that with something like that you can get everything that you
want.  A plain run in drr can do the same thing when it sees that
there's a package inforation.  Toplevel requires in the racket input
can do the same, but just requiring this file from another will not do
it which means that you can also use it this way without worrying
about interfering with real runs.  And you can also have some new
command like "raco pkg install-whatever-is-needed-for some-file.rkt"
which would be like doing the toplevel require thing.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Robby Findler]

I agree. Planet 1 currently does this.

Robby

On Friday, November 30, 2012, Eli Barzilay wrote:

> About three weeks ago, Robby Findler wrote:
> > I would be unhappy, however, if we end up with a system where you
> > have to grovel around in low-level places to get simple uses of
> > uninstalled packages working. That is, I want to be able to put in a
> > blog post or in a talk or somewhere a little program that depends on
> > uninstalled libraries and, if I'm careful about keeping those
> > libraries that the little file works with, then that file should
> > Just Work for casual users who download drracket paste it in, and
> > hit Run.
>
> IIUC, there is an API interface for installing packages, so it's
> possible to write some expression that installs a package if it is not
> installed.  The road from there to a require form that installs
> something automatically if needed is probably not long, but I think
> that one main thing that would make things better is if that results
> in some visible output about the installation that is being done.
> This avoids the problem of people who think that your random blogged
> code is not doing anything.
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Asumu Takikawa]

On 2012-11-29 13:28:03 -0700, Jay McCarthy wrote:
> That is my suggestion to developers.
>
> I think all installed packages should be either local links or named
> by the naming service. All the other package source modes are for
> people doing creative things, like maintaining their own sets of
> packages for deployments, etc.

Could "--link" be the default for local directory packages then?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Thu, Nov 29, 2012 at 1:23 PM, Asumu Takikawa  wrote:
> On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote:
>> The changes are small, so far, but the most prominent change is that
>> the interpretation of a package source is now determined syntactically.
>> If you want to install from a local directory "fish-tank", you need to
>> write
>>
>>  raco pkg install fish-tank/
>
> This is nice, I've been confused by the old behavior before.
>
> One thing that doesn't work (in either the old or current setup) is
> paths with "." or "..":
>   raco pkg install ./
>   raco pkg install ../
>
> Also, is there any reason why the `update` command can't work with
> packages from local directories?

It assumes that the directory won't be there anymore... I guess that's
a bad assumption.

> Or should I just use "--link" for these
> cases?

That is my suggestion to developers.

I think all installed packages should be either local links or named
by the naming service. All the other package source modes are for
people doing creative things, like maintaining their own sets of
packages for deployments, etc.

Jay

>
> Cheers,
> Asumu
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev



--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Asumu Takikawa]

On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote:
> The changes are small, so far, but the most prominent change is that
> the interpretation of a package source is now determined syntactically.
> If you want to install from a local directory "fish-tank", you need to
> write
>
>  raco pkg install fish-tank/

This is nice, I've been confused by the old behavior before.

One thing that doesn't work (in either the old or current setup) is
paths with "." or "..":
  raco pkg install ./
  raco pkg install ../

Also, is there any reason why the `update` command can't work with
packages from local directories? Or should I just use "--link" for these
cases?

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthew Flatt]

I've pushed a few changes in consultation with Jay. 

The changes are small, so far, but the most prominent change is that
the interpretation of a package source is now determined syntactically.
If you want to install from a local directory "fish-tank", you need to
write

 raco pkg install fish-tank/

or

 raco pkg install --type dir fish-tank

because

 raco pkg install fish-tank

will always contact the package name service to try to resolve "fish-tank".

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Robby Findler]

I expect we can do a better job in planet2 than we are doing in planet1 and
I am in favor of trying to find that balance.

I would be unhappy, however, if we end up with a system where you have to
grovel around in low-level places to get simple uses of uninstalled
packages working. That is, I want to be able to put in a blog post or in a
talk or somewhere a little program that depends on uninstalled libraries
and, if I'm careful about keeping those libraries that the little file
works with, then that file should Just Work for casual users who download
drracket paste it in, and hit Run.

I not mean to imply we do things just the way planet1 does them. Only that
we find a way for things to just work for casual users.

I realize that this is a hard design problem and that's why I think we
should be thinking about it early. Hopefully my underlying desire is not to
contentious!

Robby

On Monday, November 12, 2012, Sam Tobin-Hochstadt wrote:

> On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler
> > wrote:
> > On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt 
> > >
> wrote:
> >> On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy 
> >> >
> wrote:
> >>> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt <
> sa...@ccs.neu.edu > wrote:
> >>>
>  * I think the auto-installing module resolver mentioned in "Short
>  Term" is a bad idea -- it's already really easy to install packages
>  with this system, and auto-installation just introduces possibility
>  for headaches.
> >>>
> >>> I don't think it is *bad* idea, but I also don't think it is
> >>> *necessary*. But there are other people in the Racket group who think
> >>> this is totally necessary for Planet 2. I'll let them explain why.
> >>
> >> I'll look forward to that explanation.
> >
> > I think it is important that you can get a program from the web, put
> > it into DrRacket, hit run, and get Something Good to happen, without
> > having to go type at command lines and whatnot. (This is especially
> > true for Windows, the platform something like 95% of our users use.)
>
> I agree entirely that we need a non-command-line way of installing
> packages, and we should provide a GUI for handling that in DrRacket.
>
> I think that the percentage of our users that install new packages is
> much less Windows-heavy than the overall user base.
>
> I think a system where DrRacket can, in some modes, prompt the user to
> install packages would be a big improvement over automatic
> installation.  Right now, running a file can trigger automatic
> installation of arbitrary numbers of packages, some of which then
> conflict or which have errors that the user can't be expected to
> understand.  This is even worse when the user didn't know anything
> about the packages being installed.
>
> Sam
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Thu, Nov 8, 2012 at 1:01 PM, Sam Tobin-Hochstadt  wrote:
> I have one larger design issue, which I want to write up in a separate mail.

The larger issue is that we should allow packages to have their own
versions of other packages/collections/etc, specified in their
metadata file.  This would be less ambitious than what Planet1 does,
where a single running Racket program can have two copies of the same
planet package, but would let the programmer handle situations where
conflicts exist.

Here's an example: package A depends on package B.  I want to use
package A in my program P, but I need it to use a fixed version of
package B.  However, I don't want to make a global change to the state
of my planet cache.  So in my `package.rktd` file for P, I specify
that B should be obtained from my fork of B on GitHub.  This change is
self-contained, and doesn't require changes to any of the rest of the
system.

This is how the node.js package manager NPM works.  It implies that
most node.js programs have a full copy of their dependencies in their
installation directory -- they in general avoid global installation.
I'm not sure we should go that far, but I think making it possible is
very useful.  I know people who've had exactly the situation in my
example, which they worked around using this capability of NPM.

I'm not sure this can be done purely by Planet2, it may require more
capabilities from Racket, probably in changing how the links data is
specified.
--
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Mon, Nov 12, 2012 at 2:15 PM, Sam Tobin-Hochstadt  wrote:
> On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler
>  wrote:
>> On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt  
>> wrote:
>>> On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy  wrote:
 On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt  
 wrote:

> * I think the auto-installing module resolver mentioned in "Short
> Term" is a bad idea -- it's already really easy to install packages
> with this system, and auto-installation just introduces possibility
> for headaches.

 I don't think it is *bad* idea, but I also don't think it is
 *necessary*. But there are other people in the Racket group who think
 this is totally necessary for Planet 2. I'll let them explain why.
>>>
>>> I'll look forward to that explanation.
>>
>> I think it is important that you can get a program from the web, put
>> it into DrRacket, hit run, and get Something Good to happen, without
>> having to go type at command lines and whatnot. (This is especially
>> true for Windows, the platform something like 95% of our users use.)
>
> I agree entirely that we need a non-command-line way of installing
> packages, and we should provide a GUI for handling that in DrRacket.
>
> I think that the percentage of our users that install new packages is
> much less Windows-heavy than the overall user base.
>
> I think a system where DrRacket can, in some modes, prompt the user to
> install packages would be a big improvement over automatic
> installation.  Right now, running a file can trigger automatic
> installation of arbitrary numbers of packages, some of which then
> conflict or which have errors that the user can't be expected to
> understand.  This is even worse when the user didn't know anything
> about the packages being installed.

That's what I'm proposing as the default, btw.

Jay

>
> Sam



--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler
 wrote:
> On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt  wrote:
>> On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy  wrote:
>>> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt  
>>> wrote:
>>>
 * I think the auto-installing module resolver mentioned in "Short
 Term" is a bad idea -- it's already really easy to install packages
 with this system, and auto-installation just introduces possibility
 for headaches.
>>>
>>> I don't think it is *bad* idea, but I also don't think it is
>>> *necessary*. But there are other people in the Racket group who think
>>> this is totally necessary for Planet 2. I'll let them explain why.
>>
>> I'll look forward to that explanation.
>
> I think it is important that you can get a program from the web, put
> it into DrRacket, hit run, and get Something Good to happen, without
> having to go type at command lines and whatnot. (This is especially
> true for Windows, the platform something like 95% of our users use.)

I agree entirely that we need a non-command-line way of installing
packages, and we should provide a GUI for handling that in DrRacket.

I think that the percentage of our users that install new packages is
much less Windows-heavy than the overall user base.

I think a system where DrRacket can, in some modes, prompt the user to
install packages would be a big improvement over automatic
installation.  Right now, running a file can trigger automatic
installation of arbitrary numbers of packages, some of which then
conflict or which have errors that the user can't be expected to
understand.  This is even worse when the user didn't know anything
about the packages being installed.

Sam
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Matthias Felleisen]

On Nov 8, 2012, at 3:13 PM, Jay McCarthy wrote:

>> 
>> * I think the places you use 'PLT' in the documentation should be
>> replace with 'Racket maintainers' -- PLT is a research group with lots
>> of overlap with the Racket maintainers.
> 
> Sure.

I disagree with Sam. Racket is owned by PLT Design, Inc. And current and former 
maintainers are shareholders. PLT is a perfectly fine name. 



smime.p7s
Description: S/MIME cryptographic signature
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

This is on the long term list in the docs.

Jay

Sent from my iPhone

On 2012/11/08, at 17:59, Carl Eastlund  wrote:

Perhaps we want a GUI Planet2 installation tool?  And options for
auto-install from DrRacket to be silent, confirm/cancel, or auto-fail?
That would give us the range from full manual control to automatic
"Something Good happens", all without command lines.

Carl Eastlund


On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler
wrote:

> I think it is important that you can get a program from the web, put
> it into DrRacket, hit run, and get Something Good to happen, without
> having to go type at command lines and whatnot. (This is especially
> true for Windows, the platform something like 95% of our users use.)
>
> Robby
>
> On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt 
> wrote:
> > On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy 
> wrote:
> >> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt 
> wrote:
> >
> > [replying just to a few of these]
> >
> >>> * I think we should drop the `.plt` archive format entirely.
> >>
> >> It is the default because Racket can create it and unarchive it
> >> natively. If someone implements a native Racket zipper/unzipper, that
> >> would be great. My understanding is that this is on Eli's todo list
> >> and when it is done, it would be great to change Planet 2's default.
> >
> > Hopefully this can happen before Planet 2's release, so it wouldn't
> > need to support .plt at all.
> >
> >>> * It would be nice to have fewer special files.  For example,
> >>> `MANIFEST` could be abolished by just fetching the whole content of
> >>> the directory.  Checksums could be included in the `METADATA` file.
> >>
> >> The manifest is necessary because there's no reliable way to get a
> >> directory list from a Web site.
> >
> > Then I would just suggest dropping the web-directory fetching instead,
> > and just support archives at URLs.
> >
> >>> * In section 3.1, you should have 'git push -u origin master'.
> >>
> >> This is directly from the Github docs:
> >> https://help.github.com/articles/create-a-repo
> >
> > If you create a fresh repo on GH, you get instructions with the `-u`
> > option -- I'm surprised that they haven't updated the help site.
> >
> >>> * I thought the conclusion of a recent discussion on dev@ was that
> >>> tests, typed, etc sub-collections *are* preferred.
> >>
> >> I think I missed this conversation. I don't understand the conclusion
> >> given that we don't want to always distribute tests, for example.
> >
> > This discussion was here:
> > http://lists.racket-lang.org/dev/archive/2012-October/010507.html
> >
> > I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias
> > seems to be on the sub-collection side.
> >
> >>> * Can the Planet1 compatibility also have a version-less translation
> >>> for the latest version, so that `jaymccarthy/opencl/module` could keep
> >>> working?
> >>
> >> I don't want that version-less one to conflict with any of the other
> >> ones so that Planet 1 packages that rely on multiple versions will
> >> work. Am I missing a part of the request?
> >
> > I'm just suggesting that `../opencl` and `.../opencl1` should both exist.
> >
> >>> * I think the auto-installing module resolver mentioned in "Short
> >>> Term" is a bad idea -- it's already really easy to install packages
> >>> with this system, and auto-installation just introduces possibility
> >>> for headaches.
> >>
> >> I don't think it is *bad* idea, but I also don't think it is
> >> *necessary*. But there are other people in the Racket group who think
> >> this is totally necessary for Planet 2. I'll let them explain why.
> >
> > I'll look forward to that explanation.
> > --
> > sam th
> > sa...@ccs.neu.edu
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
 Racket Developers list:
 http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Robby Findler]

That sounds great. I imagine we'd run online check syntax in "auto
fail but put a button into the GUI" mode. That seems like an easy
decision. Maybe the default for Run would be confirm/cancel dialog box
with a "don't ask again" button or something. (I imagine it would
actually be "auto-fail" but where DrRacket notices and offers to
install with the usual "don't ask me again" check box.)

Robby

On Thu, Nov 8, 2012 at 6:57 PM, Carl Eastlund  wrote:
> Perhaps we want a GUI Planet2 installation tool?  And options for
> auto-install from DrRacket to be silent, confirm/cancel, or auto-fail?  That
> would give us the range from full manual control to automatic "Something
> Good happens", all without command lines.
>
> Carl Eastlund
>
>
>
> On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler 
> wrote:
>>
>> I think it is important that you can get a program from the web, put
>> it into DrRacket, hit run, and get Something Good to happen, without
>> having to go type at command lines and whatnot. (This is especially
>> true for Windows, the platform something like 95% of our users use.)
>>
>> Robby
>>
>> On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt 
>> wrote:
>> > On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy 
>> > wrote:
>> >> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt
>> >>  wrote:
>> >
>> > [replying just to a few of these]
>> >
>> >>> * I think we should drop the `.plt` archive format entirely.
>> >>
>> >> It is the default because Racket can create it and unarchive it
>> >> natively. If someone implements a native Racket zipper/unzipper, that
>> >> would be great. My understanding is that this is on Eli's todo list
>> >> and when it is done, it would be great to change Planet 2's default.
>> >
>> > Hopefully this can happen before Planet 2's release, so it wouldn't
>> > need to support .plt at all.
>> >
>> >>> * It would be nice to have fewer special files.  For example,
>> >>> `MANIFEST` could be abolished by just fetching the whole content of
>> >>> the directory.  Checksums could be included in the `METADATA` file.
>> >>
>> >> The manifest is necessary because there's no reliable way to get a
>> >> directory list from a Web site.
>> >
>> > Then I would just suggest dropping the web-directory fetching instead,
>> > and just support archives at URLs.
>> >
>> >>> * In section 3.1, you should have 'git push -u origin master'.
>> >>
>> >> This is directly from the Github docs:
>> >> https://help.github.com/articles/create-a-repo
>> >
>> > If you create a fresh repo on GH, you get instructions with the `-u`
>> > option -- I'm surprised that they haven't updated the help site.
>> >
>> >>> * I thought the conclusion of a recent discussion on dev@ was that
>> >>> tests, typed, etc sub-collections *are* preferred.
>> >>
>> >> I think I missed this conversation. I don't understand the conclusion
>> >> given that we don't want to always distribute tests, for example.
>> >
>> > This discussion was here:
>> > http://lists.racket-lang.org/dev/archive/2012-October/010507.html
>> >
>> > I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias
>> > seems to be on the sub-collection side.
>> >
>> >>> * Can the Planet1 compatibility also have a version-less translation
>> >>> for the latest version, so that `jaymccarthy/opencl/module` could keep
>> >>> working?
>> >>
>> >> I don't want that version-less one to conflict with any of the other
>> >> ones so that Planet 1 packages that rely on multiple versions will
>> >> work. Am I missing a part of the request?
>> >
>> > I'm just suggesting that `../opencl` and `.../opencl1` should both
>> > exist.
>> >
>> >>> * I think the auto-installing module resolver mentioned in "Short
>> >>> Term" is a bad idea -- it's already really easy to install packages
>> >>> with this system, and auto-installation just introduces possibility
>> >>> for headaches.
>> >>
>> >> I don't think it is *bad* idea, but I also don't think it is
>> >> *necessary*. But there are other people in the Racket group who think
>> >> this is totally necessary for Planet 2. I'll let them explain why.
>> >
>> > I'll look forward to that explanation.
>> > --
>> > sam th
>> > sa...@ccs.neu.edu
>> > _
>> >   Racket Developers list:
>> >   http://lists.racket-lang.org/dev
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Carl Eastlund]

Perhaps we want a GUI Planet2 installation tool?  And options for
auto-install from DrRacket to be silent, confirm/cancel, or auto-fail?
That would give us the range from full manual control to automatic
"Something Good happens", all without command lines.

Carl Eastlund


On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler
wrote:

> I think it is important that you can get a program from the web, put
> it into DrRacket, hit run, and get Something Good to happen, without
> having to go type at command lines and whatnot. (This is especially
> true for Windows, the platform something like 95% of our users use.)
>
> Robby
>
> On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt 
> wrote:
> > On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy 
> wrote:
> >> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt 
> wrote:
> >
> > [replying just to a few of these]
> >
> >>> * I think we should drop the `.plt` archive format entirely.
> >>
> >> It is the default because Racket can create it and unarchive it
> >> natively. If someone implements a native Racket zipper/unzipper, that
> >> would be great. My understanding is that this is on Eli's todo list
> >> and when it is done, it would be great to change Planet 2's default.
> >
> > Hopefully this can happen before Planet 2's release, so it wouldn't
> > need to support .plt at all.
> >
> >>> * It would be nice to have fewer special files.  For example,
> >>> `MANIFEST` could be abolished by just fetching the whole content of
> >>> the directory.  Checksums could be included in the `METADATA` file.
> >>
> >> The manifest is necessary because there's no reliable way to get a
> >> directory list from a Web site.
> >
> > Then I would just suggest dropping the web-directory fetching instead,
> > and just support archives at URLs.
> >
> >>> * In section 3.1, you should have 'git push -u origin master'.
> >>
> >> This is directly from the Github docs:
> >> https://help.github.com/articles/create-a-repo
> >
> > If you create a fresh repo on GH, you get instructions with the `-u`
> > option -- I'm surprised that they haven't updated the help site.
> >
> >>> * I thought the conclusion of a recent discussion on dev@ was that
> >>> tests, typed, etc sub-collections *are* preferred.
> >>
> >> I think I missed this conversation. I don't understand the conclusion
> >> given that we don't want to always distribute tests, for example.
> >
> > This discussion was here:
> > http://lists.racket-lang.org/dev/archive/2012-October/010507.html
> >
> > I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias
> > seems to be on the sub-collection side.
> >
> >>> * Can the Planet1 compatibility also have a version-less translation
> >>> for the latest version, so that `jaymccarthy/opencl/module` could keep
> >>> working?
> >>
> >> I don't want that version-less one to conflict with any of the other
> >> ones so that Planet 1 packages that rely on multiple versions will
> >> work. Am I missing a part of the request?
> >
> > I'm just suggesting that `../opencl` and `.../opencl1` should both exist.
> >
> >>> * I think the auto-installing module resolver mentioned in "Short
> >>> Term" is a bad idea -- it's already really easy to install packages
> >>> with this system, and auto-installation just introduces possibility
> >>> for headaches.
> >>
> >> I don't think it is *bad* idea, but I also don't think it is
> >> *necessary*. But there are other people in the Racket group who think
> >> this is totally necessary for Planet 2. I'll let them explain why.
> >
> > I'll look forward to that explanation.
> > --
> > sam th
> > sa...@ccs.neu.edu
> > _
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Robby Findler]

I think it is important that you can get a program from the web, put
it into DrRacket, hit run, and get Something Good to happen, without
having to go type at command lines and whatnot. (This is especially
true for Windows, the platform something like 95% of our users use.)

Robby

On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt  wrote:
> On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy  wrote:
>> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt  
>> wrote:
>
> [replying just to a few of these]
>
>>> * I think we should drop the `.plt` archive format entirely.
>>
>> It is the default because Racket can create it and unarchive it
>> natively. If someone implements a native Racket zipper/unzipper, that
>> would be great. My understanding is that this is on Eli's todo list
>> and when it is done, it would be great to change Planet 2's default.
>
> Hopefully this can happen before Planet 2's release, so it wouldn't
> need to support .plt at all.
>
>>> * It would be nice to have fewer special files.  For example,
>>> `MANIFEST` could be abolished by just fetching the whole content of
>>> the directory.  Checksums could be included in the `METADATA` file.
>>
>> The manifest is necessary because there's no reliable way to get a
>> directory list from a Web site.
>
> Then I would just suggest dropping the web-directory fetching instead,
> and just support archives at URLs.
>
>>> * In section 3.1, you should have 'git push -u origin master'.
>>
>> This is directly from the Github docs:
>> https://help.github.com/articles/create-a-repo
>
> If you create a fresh repo on GH, you get instructions with the `-u`
> option -- I'm surprised that they haven't updated the help site.
>
>>> * I thought the conclusion of a recent discussion on dev@ was that
>>> tests, typed, etc sub-collections *are* preferred.
>>
>> I think I missed this conversation. I don't understand the conclusion
>> given that we don't want to always distribute tests, for example.
>
> This discussion was here:
> http://lists.racket-lang.org/dev/archive/2012-October/010507.html
>
> I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias
> seems to be on the sub-collection side.
>
>>> * Can the Planet1 compatibility also have a version-less translation
>>> for the latest version, so that `jaymccarthy/opencl/module` could keep
>>> working?
>>
>> I don't want that version-less one to conflict with any of the other
>> ones so that Planet 1 packages that rely on multiple versions will
>> work. Am I missing a part of the request?
>
> I'm just suggesting that `../opencl` and `.../opencl1` should both exist.
>
>>> * I think the auto-installing module resolver mentioned in "Short
>>> Term" is a bad idea -- it's already really easy to install packages
>>> with this system, and auto-installation just introduces possibility
>>> for headaches.
>>
>> I don't think it is *bad* idea, but I also don't think it is
>> *necessary*. But there are other people in the Racket group who think
>> this is totally necessary for Planet 2. I'll let them explain why.
>
> I'll look forward to that explanation.
> --
> sam th
> sa...@ccs.neu.edu
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

The system you are describing is Planet 1. We have it, it isn't
necessarily going away. But for many users (such as Carl) it is too
expensive to have all these options and we'd like something similar.
Planet 2 is based primarily on Linux package systems, like deb/apt,
rpm, pacman, etc that lack almost all the features you describe but
have been very successful at fostering wide communities.

Jay

On Thu, Nov 8, 2012 at 3:22 PM, Tobias Hammer  wrote:
> Just out of curiosity: What are your / the teams objections against some
> kind of real versioning system that allows to
>
> * specify a version number without creating a new package
> * specify dependencies based on minimal version
> * keep/pin a package at some particular version (maybe your code
>   depends on an exact, even buggy behavior)
> * keep directory and file names between incompatible versions
>   without getting banned from solar
>
> What made me also wonder when i read the docs is, why is it allowed to
> have packets that have the same directories as the core racket distribution?
>
> Tobias
>
>
>
> On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy 
> wrote:
>
>> Now that the 5.3.1 release is finished, I've just pushed the beta release
>> of Planet 2 to the Racket core.
>>
>> I've tried to answer all questions and explain everything about Planet 2
>> in
>> the documentation, which I've uploaded a copy of here:
>>
>> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>>
>> In particular, it explains what the plan is to go from this beta release
>> to
>> the final release.
>>
>> If you currently have packages on Planet 1, I am excited to help you make
>> the transition to Planet 2. (I am currently in the process of converting
>> my
>> packages.) Please do not hesitate to let me know how I can help.
>>
>> This represents the third iteration of the design of Planet 2. (The first
>> was worked on from August 10, 2010 to March 11, 2011. The second in July
>> 2011. The third from August 2011 until now, although coding didn't begin
>> until December 2011.)
>>
>> Enjoy,
>>
>> Jay
>>
>> p.s. In the implementation, I'm particularly proud of the little language
>> for defining command-line interfaces with matching functions (see
>> planet2/main.rkt for a use) and the testing infrastructure that allows you
>> to run sequences of shell commands and check their output (see
>> tests/planet2/tests-install.rkt for a nice example.)



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Carl Eastlund]

The original Planet had explicit rules for versions, and in practice I
found they got in the way almost as often as they helped.  Worse, when they
did get in the way, there was no way around them.  I have not looked at
Planet 2 in detail yet, but it looks like it has a simpler model where
versions are dealt with directly by maintainers and clients.  So while
Planet 2 isn't doing the work for you, it's also not keeping you from doing
what you want/need to do.

This isn't ideal -- I'd really like a system that does all the nice things
you mention, Tobias -- but only once someone has a design that really gets
it "right".  Until then, I'd much rather have my options open and a system
that stays out of my way.


Carl Eastlund


On Thu, Nov 8, 2012 at 5:22 PM, Tobias Hammer  wrote:

> Just out of curiosity: What are your / the teams objections against some
> kind of real versioning system that allows to
>
> * specify a version number without creating a new package
> * specify dependencies based on minimal version
> * keep/pin a package at some particular version (maybe your code
>   depends on an exact, even buggy behavior)
> * keep directory and file names between incompatible versions
>   without getting banned from solar
>
> What made me also wonder when i read the docs is, why is it allowed to
> have packets that have the same directories as the core racket
> distribution?
>
> Tobias
>
>
>
> On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy 
> wrote:
>
>  Now that the 5.3.1 release is finished, I've just pushed the beta release
>> of Planet 2 to the Racket core.
>>
>> I've tried to answer all questions and explain everything about Planet 2
>> in
>> the documentation, which I've uploaded a copy of here:
>>
>> http://faculty.cs.byu.edu/~**jay/tmp/20121108-pkgs/planet2/**index.html
>>
>> In particular, it explains what the plan is to go from this beta release
>> to
>> the final release.
>>
>> If you currently have packages on Planet 1, I am excited to help you make
>> the transition to Planet 2. (I am currently in the process of converting
>> my
>> packages.) Please do not hesitate to let me know how I can help.
>>
>> This represents the third iteration of the design of Planet 2. (The first
>> was worked on from August 10, 2010 to March 11, 2011. The second in July
>> 2011. The third from August 2011 until now, although coding didn't begin
>> until December 2011.)
>>
>> Enjoy,
>>
>> Jay
>>
>> p.s. In the implementation, I'm particularly proud of the little language
>> for defining command-line interfaces with matching functions (see
>> planet2/main.rkt for a use) and the testing infrastructure that allows you
>> to run sequences of shell commands and check their output (see
>> tests/planet2/tests-install.**rkt for a nice example.)
>>
> _
>  Racket Developers list:
>  http://lists.racket-lang.org/**dev 
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Tobias Hammer]

Just out of curiosity: What are your / the teams objections against some
kind of real versioning system that allows to

* specify a version number without creating a new package
* specify dependencies based on minimal version
* keep/pin a package at some particular version (maybe your code
  depends on an exact, even buggy behavior)
* keep directory and file names between incompatible versions
  without getting banned from solar

What made me also wonder when i read the docs is, why is it allowed to
have packets that have the same directories as the core racket  
distribution?


Tobias


On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy   
wrote:



Now that the 5.3.1 release is finished, I've just pushed the beta release
of Planet 2 to the Racket core.

I've tried to answer all questions and explain everything about Planet 2  
in

the documentation, which I've uploaded a copy of here:

http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html

In particular, it explains what the plan is to go from this beta release  
to

the final release.

If you currently have packages on Planet 1, I am excited to help you make
the transition to Planet 2. (I am currently in the process of converting  
my

packages.) Please do not hesitate to let me know how I can help.

This represents the third iteration of the design of Planet 2. (The first
was worked on from August 10, 2010 to March 11, 2011. The second in July
2011. The third from August 2011 until now, although coding didn't begin
until December 2011.)

Enjoy,

Jay

p.s. In the implementation, I'm particularly proud of the little language
for defining command-line interfaces with matching functions (see
planet2/main.rkt for a use) and the testing infrastructure that allows  
you

to run sequences of shell commands and check their output (see
tests/planet2/tests-install.rkt for a nice example.)

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy  wrote:
> On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt  
> wrote:

[replying just to a few of these]

>> * I think we should drop the `.plt` archive format entirely.
>
> It is the default because Racket can create it and unarchive it
> natively. If someone implements a native Racket zipper/unzipper, that
> would be great. My understanding is that this is on Eli's todo list
> and when it is done, it would be great to change Planet 2's default.

Hopefully this can happen before Planet 2's release, so it wouldn't
need to support .plt at all.

>> * It would be nice to have fewer special files.  For example,
>> `MANIFEST` could be abolished by just fetching the whole content of
>> the directory.  Checksums could be included in the `METADATA` file.
>
> The manifest is necessary because there's no reliable way to get a
> directory list from a Web site.

Then I would just suggest dropping the web-directory fetching instead,
and just support archives at URLs.

>> * In section 3.1, you should have 'git push -u origin master'.
>
> This is directly from the Github docs:
> https://help.github.com/articles/create-a-repo

If you create a fresh repo on GH, you get instructions with the `-u`
option -- I'm surprised that they haven't updated the help site.

>> * I thought the conclusion of a recent discussion on dev@ was that
>> tests, typed, etc sub-collections *are* preferred.
>
> I think I missed this conversation. I don't understand the conclusion
> given that we don't want to always distribute tests, for example.

This discussion was here:
http://lists.racket-lang.org/dev/archive/2012-October/010507.html

I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias
seems to be on the sub-collection side.

>> * Can the Planet1 compatibility also have a version-less translation
>> for the latest version, so that `jaymccarthy/opencl/module` could keep
>> working?
>
> I don't want that version-less one to conflict with any of the other
> ones so that Planet 1 packages that rely on multiple versions will
> work. Am I missing a part of the request?

I'm just suggesting that `../opencl` and `.../opencl1` should both exist.

>> * I think the auto-installing module resolver mentioned in "Short
>> Term" is a bad idea -- it's already really easy to install packages
>> with this system, and auto-installation just introduces possibility
>> for headaches.
>
> I don't think it is *bad* idea, but I also don't think it is
> *necessary*. But there are other people in the Racket group who think
> this is totally necessary for Planet 2. I'll let them explain why.

I'll look forward to that explanation.
--
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Thu, Nov 8, 2012 at 1:49 PM, Eli Barzilay  wrote:
> 30 minutes ago, Jay McCarthy wrote:
>> > IIUC, the branch in the path is required, is that the case?  If
>> > so, then I think that it should really work without it too, to get
>> > the simple https://github.com/user/repo syntax.
>>
>> Yes it is required. We could do that, right now there's not
>> assumptions like this (i.e. you always want master) anywhere else in
>> the system so I didn't do it.
>
> I think that such assumptions are very common, especially in the
> github world.  Since it's still just a URL thing and it's easy to add,
> I think that GH users would expect it to work.

I'll enable it on the PNS so that it will automatically add the master
branch and when you submit and http github address it will ask if you
mean github://

Jay

--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Thu, Nov 8, 2012 at 1:48 PM, Eli Barzilay  wrote:
> 20 minutes ago, Jay McCarthy wrote:
>> > * I think tying to GitHub is a mistake -- the system should work
>> > for for arbitrary Git repositories.  Having a short syntax for
>> > github is great, though.  Additionally, we should support fixing a
>> > checksum for a package.  The npm docs have a similar list of
>> > things that can be installed here:
>> > https://npmjs.org/doc/install.html
>>
>> Github automatically generates zip/tgz files. Planet 2 knows nothing
>> about Github other than this and the URL structure of their site to
>> get them and the checksums.
>
> This is something that many (probably all) git places do -- and even
> the gitweb script that we're using on git.racket-lang.org knows how to
> do.  (See the "zip" and "tar.gz" links.)  In any case, since this is
> just a URL format thing, it should be easy to put it in some place
> that could be easily extended for other places, and possibly
> pluggable.

I'm fine with that... but I don't have the bandwidth to develop it for
anything I don't use.

>
>> If you'd like to implement general git support, I think that would
>> be great, but it is more work than I have time to do. I can point
>> you in the right direction.
>
> If you have a "git" command, then it's a simple matter of using "git
> archive".  There's some robust git looking in the repo-time-stamp
> collection that could be lifted up for this.
>

Yes I was going to that first, but (a) I didn't want to rely on the
git command and (b) github doesn't support "git archive".

>> > * I think we should drop the `.plt` archive format entirely.
>>
>> It is the default because Racket can create it and unarchive it
>> natively.  If someone implements a native Racket zipper/unzipper,
>> that would be great. My understanding is that this is on Eli's todo
>> list and when it is done, it would be great to change Planet 2's
>> default.
>
> How about requiring a format for now, to avoid changing the default
> later?

I'll do that.

>
>> The checksum can't be in the metadata because the metadata is in the
>> archive, but you need to be able to get the checksum without getting
>> the archive.
>
> (Is the checksum only needed for detecting updates?  If so, then why
> not use just the timestamp?)

The checksum is just a string, with no interpretation, you could use a
timestamp as yours. In the case of github though, I can easily get the
checksum but not a timestamp.

>> > * Similarly, the names of the special files could avoid ALL-CAPS,
>> > and I'd go with the name 'package' rather than `metadata`.
>>
>> I have no preference about this shed color. If others feel strongly,
>> it can change.
>
> I do.  It would be better IMO to look at existing packagers and reuse
> some of their conventions.  (I know that at least the chrome packages
> have similar things, and I liked their design.)

I based the convention off CPAN with its META.yml file.

>> > * In section 3.1, you should have 'git push -u origin master'.
>>
>> This is directly from the Github docs:
>> https://help.github.com/articles/create-a-repo
>
> Using -u is much better.  The reason it is not in the github page is
> possibly that they're aiming at ancient git versions that didn't have
> it.  (IIRC, when we migrated to git this option was new, and should be
> safe to assume that everyone has it now...)  (Also, I'm not sure how
> well they maintain those help pages -- they had a few more educational
> projects since we migrated, and recently there's something even more
> ambitious.)
>

Changed.

>> > * I thought the conclusion of a recent discussion on dev@ was that
>> > tests, typed, etc sub-collections *are* preferred.
>>
>> I think I missed this conversation.  I don't understand the
>> conclusion given that we don't want to always distribute tests, for
>> example.
>
> It should be possible to distribute the separate parts regardless of
> where they are.  The thing is that with a single directory management
> of code is much easier.  Eventually, many of the collections in the
> current tree should move out into their own repositories.

In any case, I've missed it and will make the change to the
recommendations, although personally I like having separate
directories like tests because it doesn't clutter my main code
directory.

Jay


--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

30 minutes ago, Jay McCarthy wrote:
> > IIUC, the branch in the path is required, is that the case?  If
> > so, then I think that it should really work without it too, to get
> > the simple https://github.com/user/repo syntax.
> 
> Yes it is required. We could do that, right now there's not
> assumptions like this (i.e. you always want master) anywhere else in
> the system so I didn't do it.

I think that such assumptions are very common, especially in the
github world.  Since it's still just a URL thing and it's easy to add,
I think that GH users would expect it to work.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

20 minutes ago, Jay McCarthy wrote:
> > * I think tying to GitHub is a mistake -- the system should work
> > for for arbitrary Git repositories.  Having a short syntax for
> > github is great, though.  Additionally, we should support fixing a
> > checksum for a package.  The npm docs have a similar list of
> > things that can be installed here:
> > https://npmjs.org/doc/install.html
> 
> Github automatically generates zip/tgz files. Planet 2 knows nothing
> about Github other than this and the URL structure of their site to
> get them and the checksums.

This is something that many (probably all) git places do -- and even
the gitweb script that we're using on git.racket-lang.org knows how to
do.  (See the "zip" and "tar.gz" links.)  In any case, since this is
just a URL format thing, it should be easy to put it in some place
that could be easily extended for other places, and possibly
pluggable.


> If you'd like to implement general git support, I think that would
> be great, but it is more work than I have time to do. I can point
> you in the right direction.

If you have a "git" command, then it's a simple matter of using "git
archive".  There's some robust git looking in the repo-time-stamp
collection that could be lifted up for this.


> > * I think we should drop the `.plt` archive format entirely.
> 
> It is the default because Racket can create it and unarchive it
> natively.  If someone implements a native Racket zipper/unzipper,
> that would be great. My understanding is that this is on Eli's todo
> list and when it is done, it would be great to change Planet 2's
> default.

How about requiring a format for now, to avoid changing the default
later?


> The checksum can't be in the metadata because the metadata is in the
> archive, but you need to be able to get the checksum without getting
> the archive.

(Is the checksum only needed for detecting updates?  If so, then why
not use just the timestamp?)


> > * Similarly, the names of the special files could avoid ALL-CAPS,
> > and I'd go with the name 'package' rather than `metadata`.
> 
> I have no preference about this shed color. If others feel strongly,
> it can change.

I do.  It would be better IMO to look at existing packagers and reuse
some of their conventions.  (I know that at least the chrome packages
have similar things, and I liked their design.)


> > * In section 3.1, you should have 'git push -u origin master'.
> 
> This is directly from the Github docs:
> https://help.github.com/articles/create-a-repo

Using -u is much better.  The reason it is not in the github page is
possibly that they're aiming at ancient git versions that didn't have
it.  (IIRC, when we migrated to git this option was new, and should be
safe to assume that everyone has it now...)  (Also, I'm not sure how
well they maintain those help pages -- they had a few more educational
projects since we migrated, and recently there's something even more
ambitious.)


> > * I thought the conclusion of a recent discussion on dev@ was that
> > tests, typed, etc sub-collections *are* preferred.
> 
> I think I missed this conversation.  I don't understand the
> conclusion given that we don't want to always distribute tests, for
> example.

It should be possible to distribute the separate parts regardless of
where they are.  The thing is that with a single directory management
of code is much easier.  Eventually, many of the collections in the
current tree should move out into their own repositories.

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Thu, Nov 8, 2012 at 11:35 AM, Eli Barzilay  wrote:
> Jay: do you prefer off-line commentage?

No, this is fine.

> Meanwhile, I'll re-use some of Sam's text (I generally +1 all items
> that I have omitted):

I won't respond to points that I feel were answered re: Sam.

> 20 minutes ago, Sam Tobin-Hochstadt wrote:
>>
>> * I think tying to GitHub is a mistake -- the system should work for
>> for arbitrary Git repositories.
>
> I very much agree with this -- but I don't want to see github support
> gone, just have it added as some plugin into the whole thing that can
> make github easier to work with.  With something like this it will be
> easy to write new ones for other places when people want them.
>
>
>> Having a short syntax for github is great, though.
>
> IIUC, the branch in the path is required, is that the case?  If so,
> then I think that it should really work without it too, to get the
> simple https://github.com/user/repo syntax.

Yes it is required. We could do that, right now there's not
assumptions like this (i.e. you always want master) anywhere else in
the system so I didn't do it.

>> * I think we should drop the `.plt` archive format entirely.
>
> +17.  I don't think that it can be removed completely though, but it
> definitely sounds like a mistake to use it as the default for creating
> new packages.
>
>
>> * It would be nice to have fewer special files.  For example,
>> `MANIFEST` could be abolished by just fetching the whole content of
>> the directory.  Checksums could be included in the `METADATA` file.
>
> +1 for fewer files.
>
> As for Sam's comment on MANIFEST -- I disagree with that -- it *is*
> required if you want to just make the files visible on some web page.
> (Since you cannot rely on a directory listing.)  It could be optional
> for formats that have a way to get that list though.

It is optional for those formats now. It is only used when you use the
remote directory URL source.

>> * Similarly, the names of the special files could avoid ALL-CAPS,
>> and I'd go with the name 'package' rather than `metadata`.
>
> Excited +1 for both!  (When I look at a directory listing, I'd like
> them to be de-emphasized.)
>
>
>> * We really need valid SSL certificates for any user-facing sites.
>> StartSSL gives them away for free: http://www.startssl.com/
>
> (Last time I looked, free SSLs weren't ones that would get trusted by
> default popular browsers.  If you're talking about some certificate,
> then making them is easy.)
>
>
>> * I thought the conclusion of a recent discussion on dev@ was that
>> tests, typed, etc sub-collections *are* preferred.
>
> Yes -- I said that, with the strong preference for projects being a
> self-contained directory, which would make management much simpler.
> (On authors, clients, and code.)
>
> --
>   ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
> http://barzilay.org/   Maze is Life!



--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt  wrote:
> On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy  wrote:
>> Now that the 5.3.1 release is finished, I've just pushed the beta release of
>> Planet 2 to the Racket core.
>
> Here, as promised, more detailed but small comments.  I have one
> larger design issue, which I want to write up in a separate mail.
>
> * I think the places you use 'PLT' in the documentation should be
> replace with 'Racket maintainers' -- PLT is a research group with lots
> of overlap with the Racket maintainers.

Sure.

> * I think tying to GitHub is a mistake -- the system should work for
> for arbitrary Git repositories.  Having a short syntax for github is
> great, though.  Additionally, we should support fixing a checksum for
> a package.  The npm docs have a similar list of things that can be
> installed here: https://npmjs.org/doc/install.html

Github automatically generates zip/tgz files. Planet 2 knows nothing
about Github other than this and the URL structure of their site to
get them and the checksums.

If you'd like to implement general git support, I think that would be
great, but it is more work than I have time to do. I can point you in
the right direction.

> * I think we should drop the `.plt` archive format entirely.

It is the default because Racket can create it and unarchive it
natively. If someone implements a native Racket zipper/unzipper, that
would be great. My understanding is that this is on Eli's todo list
and when it is done, it would be great to change Planet 2's default.

> * It would be nice to have a command-line way of publishing a package
> to a name service.

I don't want to legislate how that works, force all service to support
publishing, or reimplement the pieces of the Web browser that submit
the forms, etc. Additionally, I expect you do this rarely.

> * I think use 'dont-' in command line arguments is potentially
> confusing, and the 'no-' prefix is more common in other software.

I have no preference about this shed color. If others feel strongly,
it can change.

> * It would be nice to have fewer special files.  For example,
> `MANIFEST` could be abolished by just fetching the whole content of
> the directory.  Checksums could be included in the `METADATA` file.

The manifest is necessary because there's no reliable way to get a
directory list from a Web site.

The checksum can't be in the metadata because the metadata is in the
archive, but you need to be able to get the checksum without getting
the archive.

> * Similarly, the names of the special files could avoid ALL-CAPS, and
> I'd go with the name 'package' rather than `metadata`.

I have no preference about this shed color. If others feel strongly,
it can change.

> * I think 'update' with no arguments shouldn't do a global operation;
> use `-a/--all` for that, otherwise it's easy (say in scripts) to
> accidentally trigger the global behavior.

I'll make this change soon.

> * In section 3.1, you should have 'git push -u origin master'.

This is directly from the Github docs:
https://help.github.com/articles/create-a-repo

> * We really need valid SSL certificates for any user-facing sites.
> StartSSL gives them away for free: http://www.startssl.com/

I agree that the Racket maintainers should buy something like this.

> * I thought the conclusion of a recent discussion on dev@ was that
> tests, typed, etc sub-collections *are* preferred.

I think I missed this conversation. I don't understand the conclusion
given that we don't want to always distribute tests, for example.

> * Can the Planet1 compatibility also have a version-less translation
> for the latest version, so that `jaymccarthy/opencl/module` could keep
> working?

I don't want that version-less one to conflict with any of the other
ones so that Planet 1 packages that rely on multiple versions will
work. Am I missing a part of the request?

> * I think the auto-installing module resolver mentioned in "Short
> Term" is a bad idea -- it's already really easy to install packages
> with this system, and auto-installation just introduces possibility
> for headaches.

I don't think it is *bad* idea, but I also don't think it is
*necessary*. But there are other people in the Racket group who think
this is totally necessary for Planet 2. I'll let them explain why.

Jay

--
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Thu, Nov 8, 2012 at 1:35 PM, Eli Barzilay  wrote:
>
>> * We really need valid SSL certificates for any user-facing sites.
>> StartSSL gives them away for free: http://www.startssl.com/
>
> (Last time I looked, free SSLs weren't ones that would get trusted by
> default popular browsers.  If you're talking about some certificate,
> then making them is easy.)

This is not correct -- StartSSL is in the trust root for major
browsers.  See http://en.wikipedia.org/wiki/StartCom for details,
which I confirmed on Firefox.
--
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Eli Barzilay]

Jay: do you prefer off-line commentage?

Meanwhile, I'll re-use some of Sam's text (I generally +1 all items
that I have omitted):


20 minutes ago, Sam Tobin-Hochstadt wrote:
> 
> * I think tying to GitHub is a mistake -- the system should work for
> for arbitrary Git repositories.

I very much agree with this -- but I don't want to see github support
gone, just have it added as some plugin into the whole thing that can
make github easier to work with.  With something like this it will be
easy to write new ones for other places when people want them.


> Having a short syntax for github is great, though.

IIUC, the branch in the path is required, is that the case?  If so,
then I think that it should really work without it too, to get the
simple https://github.com/user/repo syntax.


> * I think we should drop the `.plt` archive format entirely.

+17.  I don't think that it can be removed completely though, but it
definitely sounds like a mistake to use it as the default for creating
new packages.


> * It would be nice to have fewer special files.  For example,
> `MANIFEST` could be abolished by just fetching the whole content of
> the directory.  Checksums could be included in the `METADATA` file.

+1 for fewer files.

As for Sam's comment on MANIFEST -- I disagree with that -- it *is*
required if you want to just make the files visible on some web page.
(Since you cannot rely on a directory listing.)  It could be optional
for formats that have a way to get that list though.


> * Similarly, the names of the special files could avoid ALL-CAPS,
> and I'd go with the name 'package' rather than `metadata`.

Excited +1 for both!  (When I look at a directory listing, I'd like
them to be de-emphasized.)


> * We really need valid SSL certificates for any user-facing sites.
> StartSSL gives them away for free: http://www.startssl.com/

(Last time I looked, free SSLs weren't ones that would get trusted by
default popular browsers.  If you're talking about some certificate,
then making them is easy.)


> * I thought the conclusion of a recent discussion on dev@ was that
> tests, typed, etc sub-collections *are* preferred.

Yes -- I said that, with the strong preference for projects being a
self-contained directory, which would make management much simpler.
(On authors, clients, and code.)

-- 
  ((lambda (x) (x x)) (lambda (x) (x x)))  Eli Barzilay:
http://barzilay.org/   Maze is Life!
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Asumu Takikawa]

On 2012-11-08 06:16:58 -0700, Jay McCarthy wrote:
>Now that the 5.3.1 release is finished, I've just pushed the beta
>release of Planet 2 to the Racket core.

Very nice! I'll provide some feedback once I've tried to port a package.

BTW, I get an exception when I click "Log in" on this page with blank
fields:
  https://plt-etc.byu.edu:9004/manage/upload

  build-path: path element is an empty string
argument position: 2nd
  other arguments...:
 
#

Cheers,
Asumu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

This is Racket feature request.

Racket only supports the "directory require to main.rk require" on
top-level collections, not sub-collections.

Many places in the Racket core have to do this redirect manually too.

Jay

On Thu, Nov 8, 2012 at 11:02 AM, Danny Yoo  wrote:
>
>
> On Thu, Nov 8, 2012 at 6:16 AM, Jay McCarthy  wrote:
>>
>> Now that the 5.3.1 release is finished, I've just pushed the beta release
>> of Planet 2 to the Racket core.
>>
>> I've tried to answer all questions and explain everything about Planet 2
>> in the documentation, which I've uploaded a copy of here:
>>
>> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>>
>> In particular, it explains what the plan is to go from this beta release
>> to the final release.
>>
>> If you currently have packages on Planet 1, I am excited to help you make
>> the transition to Planet 2. (I am currently in the process of converting my
>> packages.) Please do not hesitate to let me know how I can help.
>>
>
> Another issue: main.rkt doesn't seem to be working for me.  Here's what I'm
> seeing:
>
> I have a link to a local package:
>
>
> bash-3.2$ ~/local/racket/bin/raco pkg show
> Package(auto?)ChecksumSource
> c 81c46fbc1ce318f2733ad9dfce10930be3b4c93a(pns c)
> stardate  #f  (link
> /Users/dyoo/work/stardate)
>
>
> whose directory structure is:
>
> bash-3.2$ ls -l stardate
> total 0
> drwxr-xr-x  3 dyoo  staff  102 Nov  8 10:48 date
> bash-3.2$ ls -l stardate/date
> total 0
> drwxr-xr-x  9 dyoo  staff  306 Nov  8 10:53 stardate
> bash-3.2$ ls -l stardate/date/stardate
> total 48
> drwxr-xr-x  8 dyoo  staff   272 Nov  8 10:52 compiled
> -rw-r--r--  1 dyoo  staff   422 Nov  8 10:49 info.rkt
> -rw-r--r--  1 dyoo  staff   422 Nov  8 10:47 info.rkt~
> -rw-r--r--  1 dyoo  staff91 Nov  8 10:47 main.rkt
> -rw-r--r--  1 dyoo  staff   776 Nov  8 10:53 manual.scrbl
> -rw-r--r--  1 dyoo  staff   771 Nov  8 10:51 manual.scrbl~
> -rw-r--r--  1 dyoo  staff  1734 Nov  8 10:47 tng-stardate.rkt
>
>
>
> When I try to require date/stardate, I see the following error message:
>
>
>> (require date/stardate)
> default-load-handler: cannot open input file
>   path: /Users/dyoo/work/stardate/date/stardate.rkt
>   system error: No such file or directory; errno=2
>   context...:
>standard-module-name-resolver
>/Users/dyoo/local/racket/collects/racket/private/misc.rkt:87:7
>
>
> However, I can still refer to the main module explicitly:
>
>
>> (require date/stardate/main)
>
>
> So something about the resolution of main.rkt isn't working yet.  What other
> debugging info can I provide?



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Danny Yoo]

On Thu, Nov 8, 2012 at 6:16 AM, Jay McCarthy  wrote:

> Now that the 5.3.1 release is finished, I've just pushed the beta release
> of Planet 2 to the Racket core.
>
> I've tried to answer all questions and explain everything about Planet 2
> in the documentation, which I've uploaded a copy of here:
>
> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>
> In particular, it explains what the plan is to go from this beta release
> to the final release.
>
> If you currently have packages on Planet 1, I am excited to help you make
> the transition to Planet 2. (I am currently in the process of converting my
> packages.) Please do not hesitate to let me know how I can help.
>
>
Another issue: main.rkt doesn't seem to be working for me.  Here's what I'm
seeing:

I have a link to a local package:


bash-3.2$ ~/local/racket/bin/raco pkg show
Package(auto?)ChecksumSource
c 81c46fbc1ce318f2733ad9dfce10930be3b4c93a(pns c)
stardate  #f  (link
/Users/dyoo/work/stardate)


whose directory structure is:

bash-3.2$ ls -l stardate
total 0
drwxr-xr-x  3 dyoo  staff  102 Nov  8 10:48 date
bash-3.2$ ls -l stardate/date
total 0
drwxr-xr-x  9 dyoo  staff  306 Nov  8 10:53 stardate
bash-3.2$ ls -l stardate/date/stardate
total 48
drwxr-xr-x  8 dyoo  staff   272 Nov  8 10:52 compiled
-rw-r--r--  1 dyoo  staff   422 Nov  8 10:49 info.rkt
-rw-r--r--  1 dyoo  staff   422 Nov  8 10:47 info.rkt~
-rw-r--r--  1 dyoo  staff91 Nov  8 10:47 main.rkt
-rw-r--r--  1 dyoo  staff   776 Nov  8 10:53 manual.scrbl
-rw-r--r--  1 dyoo  staff   771 Nov  8 10:51 manual.scrbl~
-rw-r--r--  1 dyoo  staff  1734 Nov  8 10:47 tng-stardate.rkt



When I try to require date/stardate, I see the following error message:


> (require date/stardate)
default-load-handler: cannot open input file
  path: /Users/dyoo/work/stardate/date/stardate.rkt
  system error: No such file or directory; errno=2
  context...:
   standard-module-name-resolver
   /Users/dyoo/local/racket/collects/racket/private/misc.rkt:87:7


However, I can still refer to the main module explicitly:


> (require date/stardate/main)


So something about the resolution of main.rkt isn't working yet.  What
other debugging info can I provide?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy  wrote:
> Now that the 5.3.1 release is finished, I've just pushed the beta release of
> Planet 2 to the Racket core.

Here, as promised, more detailed but small comments.  I have one
larger design issue, which I want to write up in a separate mail.

* I think the places you use 'PLT' in the documentation should be
replace with 'Racket maintainers' -- PLT is a research group with lots
of overlap with the Racket maintainers.

* I think tying to GitHub is a mistake -- the system should work for
for arbitrary Git repositories.  Having a short syntax for github is
great, though.  Additionally, we should support fixing a checksum for
a package.  The npm docs have a similar list of things that can be
installed here: https://npmjs.org/doc/install.html

* I think we should drop the `.plt` archive format entirely.

* It would be nice to have a command-line way of publishing a package
to a name service.

* I think use 'dont-' in command line arguments is potentially
confusing, and the 'no-' prefix is more common in other software.

* It would be nice to have fewer special files.  For example,
`MANIFEST` could be abolished by just fetching the whole content of
the directory.  Checksums could be included in the `METADATA` file.

* Similarly, the names of the special files could avoid ALL-CAPS, and
I'd go with the name 'package' rather than `metadata`.

* I think 'update' with no arguments shouldn't do a global operation;
use `-a/--all` for that, otherwise it's easy (say in scripts) to
accidentally trigger the global behavior.

* In section 3.1, you should have 'git push -u origin master'.

* We really need valid SSL certificates for any user-facing sites.
StartSSL gives them away for free: http://www.startssl.com/

* I thought the conclusion of a recent discussion on dev@ was that
tests, typed, etc sub-collections *are* preferred.

* Can the Planet1 compatibility also have a version-less translation
for the latest version, so that `jaymccarthy/opencl/module` could keep
working?

* I think the auto-installing module resolver mentioned in "Short
Term" is a bad idea -- it's already really easy to install packages
with this system, and auto-installation just introduces possibility
for headaches.

--
sam th
sa...@ccs.neu.edu
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Danny Yoo]

On Thu, Nov 8, 2012 at 10:12 AM, Neil Toronto wrote:

> On 11/08/2012 06:16 AM, Jay McCarthy wrote:
>
>> Now that the 5.3.1 release is finished, I've just pushed the beta
>> release of Planet 2 to the Racket core.
>>
>
> I just read the docs. This is friggin' awesome.



Quick comment: the install instructions should not be shown with hover.
 Here's why: I view the page for a package.  Cool, new package.  Let me
open up DrRacket.  Oh, wait, my window focus isn't over that link anymore,
so I can't see the install instructions.  :)

What about putting the install instructions in the right margin, similar to
a margin-note?
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Neil Toronto]

On 11/08/2012 06:16 AM, Jay McCarthy wrote:

Now that the 5.3.1 release is finished, I've just pushed the beta
release of Planet 2 to the Racket core.


I just read the docs. This is friggin' awesome.

Neil ⊥

_
 Racket Developers list:
 http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Jay McCarthy]

Yup, that's the idea. Although I imagine most people will find Github
the best option since you don't need to anything you aren't already
doing. (That is, the manual option requires you to do "raco create"
and then upload the file, whereas when you use Github you always "git
push" anyways.)

On Thu, Nov 8, 2012 at 8:49 AM, Ray Racine  wrote:
> Huge!!!
>
> The manual deployment at first glance appears to allow the use of the
> various "cloud drives" as deployment options.  Drop a x.plt file onto Amazon
> S3, or Google GDrive or Ubuntu One,  which are for all intents and purposes
> essentially free,  make it publicly accessible and announce the URL.  And
> Git support, thank you.  Planet2 will be key to community growth.
>
>
> On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy  wrote:
>>
>> Now that the 5.3.1 release is finished, I've just pushed the beta release
>> of Planet 2 to the Racket core.
>>
>> I've tried to answer all questions and explain everything about Planet 2
>> in the documentation, which I've uploaded a copy of here:
>>
>> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>>
>> In particular, it explains what the plan is to go from this beta release
>> to the final release.
>>
>> If you currently have packages on Planet 1, I am excited to help you make
>> the transition to Planet 2. (I am currently in the process of converting my
>> packages.) Please do not hesitate to let me know how I can help.
>>
>> This represents the third iteration of the design of Planet 2. (The first
>> was worked on from August 10, 2010 to March 11, 2011. The second in July
>> 2011. The third from August 2011 until now, although coding didn't begin
>> until December 2011.)
>>
>> Enjoy,
>>
>> Jay
>>
>> p.s. In the implementation, I'm particularly proud of the little language
>> for defining command-line interfaces with matching functions (see
>> planet2/main.rkt for a use) and the testing infrastructure that allows you
>> to run sequences of shell commands and check their output (see
>> tests/planet2/tests-install.rkt for a nice example.)
>>
>> --
>> Jay McCarthy 
>> Assistant Professor / Brigham Young University
>> http://faculty.cs.byu.edu/~jay
>>
>> "The glory of God is Intelligence" - D&C 93
>>
>> _
>>   Racket Developers list:
>>   http://lists.racket-lang.org/dev
>>
>



-- 
Jay McCarthy 
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Ray Racine]

Huge!!!

The manual deployment at first glance appears to allow the use of the
various "cloud drives" as deployment options.  Drop a x.plt file onto
Amazon S3, or Google GDrive or Ubuntu One,  which are for all intents and
purposes essentially free,  make it publicly accessible and announce the
URL.  And Git support, thank you.  Planet2 will be key to community growth.


On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy  wrote:

> Now that the 5.3.1 release is finished, I've just pushed the beta release
> of Planet 2 to the Racket core.
>
> I've tried to answer all questions and explain everything about Planet 2
> in the documentation, which I've uploaded a copy of here:
>
> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>
> In particular, it explains what the plan is to go from this beta release
> to the final release.
>
> If you currently have packages on Planet 1, I am excited to help you make
> the transition to Planet 2. (I am currently in the process of converting my
> packages.) Please do not hesitate to let me know how I can help.
>
> This represents the third iteration of the design of Planet 2. (The first
> was worked on from August 10, 2010 to March 11, 2011. The second in July
> 2011. The third from August 2011 until now, although coding didn't begin
> until December 2011.)
>
> Enjoy,
>
> Jay
>
> p.s. In the implementation, I'm particularly proud of the little language
> for defining command-line interfaces with matching functions (see
> planet2/main.rkt for a use) and the testing infrastructure that allows you
> to run sequences of shell commands and check their output (see
> tests/planet2/tests-install.rkt for a nice example.)
>
> --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Sam Tobin-Hochstadt]

Impressive!

I've looked over the docs, and while I have lots of comments that I'll post
later, I want to say that this is a very nice design, and hits exactly the
right spot.  I'm really excited about what this holds for Racket.

Sam
On Nov 8, 2012 8:17 AM, "Jay McCarthy"  wrote:

> Now that the 5.3.1 release is finished, I've just pushed the beta release
> of Planet 2 to the Racket core.
>
> I've tried to answer all questions and explain everything about Planet 2
> in the documentation, which I've uploaded a copy of here:
>
> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>
> In particular, it explains what the plan is to go from this beta release
> to the final release.
>
> If you currently have packages on Planet 1, I am excited to help you make
> the transition to Planet 2. (I am currently in the process of converting my
> packages.) Please do not hesitate to let me know how I can help.
>
> This represents the third iteration of the design of Planet 2. (The first
> was worked on from August 10, 2010 to March 11, 2011. The second in July
> 2011. The third from August 2011 until now, although coding didn't begin
> until December 2011.)
>
> Enjoy,
>
> Jay
>
> p.s. In the implementation, I'm particularly proud of the little language
> for defining command-line interfaces with matching functions (see
> planet2/main.rkt for a use) and the testing infrastructure that allows you
> to run sequences of shell commands and check their output (see
> tests/planet2/tests-install.rkt for a nice example.)
>
> --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev

Re: [racket-dev] Planet 2 Beta Release

[Carl Eastlund]

Thanks, Jay!  This is great news.  After my dissertation defense next week,
I imagine I'll be putting Planet 2 to the test.

Carl Eastlund


On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy  wrote:

> Now that the 5.3.1 release is finished, I've just pushed the beta release
> of Planet 2 to the Racket core.
>
> I've tried to answer all questions and explain everything about Planet 2
> in the documentation, which I've uploaded a copy of here:
>
> http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html
>
> In particular, it explains what the plan is to go from this beta release
> to the final release.
>
> If you currently have packages on Planet 1, I am excited to help you make
> the transition to Planet 2. (I am currently in the process of converting my
> packages.) Please do not hesitate to let me know how I can help.
>
> This represents the third iteration of the design of Planet 2. (The first
> was worked on from August 10, 2010 to March 11, 2011. The second in July
> 2011. The third from August 2011 until now, although coding didn't begin
> until December 2011.)
>
> Enjoy,
>
> Jay
>
> p.s. In the implementation, I'm particularly proud of the little language
> for defining command-line interfaces with matching functions (see
> planet2/main.rkt for a use) and the testing infrastructure that allows you
> to run sequences of shell commands and check their output (see
> tests/planet2/tests-install.rkt for a nice example.)
>
> --
> Jay McCarthy 
> Assistant Professor / Brigham Young University
> http://faculty.cs.byu.edu/~jay
>
> "The glory of God is Intelligence" - D&C 93
>
> _
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
_
  Racket Developers list:
  http://lists.racket-lang.org/dev