Re: [racket-dev] package-system update
On Sun, 21 Jul 2013 10:32:10 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew When the gui (or gui-lib) package is installed, then a Matthew gracket executable is added to bin. The starter executable Matthew is used by `raco exe' to generate executables (that sometimes Matthew refer back to gracket). Ok there is progress to report, I can now build the core package alone. However one thing is missing, the man pages are not installed by the make install phase. For openSUSE (yet it should be the same for other distros) every executable file should have a man page. Thanks Togan -- o.o.o o_o__o _o ,_o o_ | `|' (|))'),' ` |( ' (, ,( )| ' ( ) [ ] [ ]\ / \/ \/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Sat, 20 Jul 2013 10:36:09 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew At Sat, 20 Jul 2013 17:12:26 +0200, Togan Muftuoglu wrote: On Fri, 19 Jul 2013 17:43:42 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru5cw-xmd5yjdbdmrexy1tmh2...@public.gmane.org said: Matthew The documentation directory and collection directory should be Matthew configurable, now. Looks like but I still have problems with the build process as directory contents are not copied to the destinations. Matthew The share, doc, and etc directories will be empty/missing Matthew for a core build, so that's as expected. (But config vs. etc Matthew was a bug that now should be fixed.) Ok there is some progress but I am still not there. Let me briefly go over the current problems, this could be due to I am building rpm packages, but nevertheless: 1. Makefile in the main directory (not racket/src/Makefile.in) does not understand rpmmacro %_smp_mflags which basically sets the CPU and JOBS automatically setting CUPS=`/usr/bin/getconf _NPROCESSORS_ONLN` get this done easier That goes also true for %configure macro which sets most of the things based on the build machine ie /usr/lib64 for x86_64 and /usr/lib for i586. Not being able to the rpm macros makes packaging pain So currently I am avoiding using this Makefile 2. using racket/src configure for x86_64 build and make produces this make[6]: Leaving directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src/gracket' cd ..; rm -f /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/gracketcgc cd ..; rm -f /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/gracket cd ..; echo 'MROPTIONS=' /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/buildinfo cd ..; echo MRLIBS= /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/buildinfo cd ..; echo MRLDFLAGS=-pthread -L../racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/buildinfo cd ..; mkdir -p /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64; make[5]: Leaving directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src/gracket' make install-wx_xt-3m make[5]: Entering directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src/gracket' make install-lib-3m-wx_xt make[6]: Entering directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src/gracket' make[6]: Leaving directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src/gracket' cd ..; /usr/bin/libtool --mode=install cp gracket/gracket3m \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/gracket libtool: install: cp gracket/.libs/gracket3m \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-22.1.x86_64/usr/lib64/racket/gracket ^^ That should not be the case gracket is not a library file it belongs to /usr/bin gracket: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), \ dynamically linked (uses shared libs), for GNU/Linux 2.6.32, There is also starter as /usr/lib64/racket/starter which has it come down to play yet but that is also wrong location for an executable starter: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, Thanks -- o.o.o o_o__o _o ,_o o_ | `|' (|))'),' ` |( ' (, ,( )| ' ( ) [ ] [ ]\ / \/ \/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Fri, 19 Jul 2013 17:43:42 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew The documentation directory and collection directory should be Matthew configurable, now. Looks like but I still have problems with the build process as directory contents are not copied to the destinations. make install-common-middle make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src' make copytree-run make[4]: Entering directory `/home/abuild/rpmbuild/BUILD/racket-5.90.0.1/racket/src' racket/racketcgc -u \ ./../collects/setup/unixstyle-install.rkt \ make-install-copytree ./.. \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/bin \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/doc/packages/racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/lib64 \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/include/racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/lib64/racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/etc/racket \ /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/man no Copying collects - /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/racket Copying share - /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/racket missing source path share, skipping... Copying doc - /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/usr/share/doc/packages/racket missing source path doc, skipping... Copying config - /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/etc/racket missing source path config, skipping... Rewriting configuration file at: /home/abuild/rpmbuild/BUILDROOT/racket-5.90.0.1-0.x86_64/etc/racket/config.rktd... Matthew Besides starting from the git repository, you could also try out Matthew the new source snapshot: Matthew http://www.cs.utah.edu/plt/snapshots/ Matthew The label on the Source snapshots really should say something Matthew like kernel in source form, plus pre-built packages and Matthew documentation. The Minimal Racket variant doesn't have any Matthew packages, but it has the core collections pre-built, and Matthew installing a package from the main distribution gets the package Matthew in pre-built form from the snapshot site. Sorry my understanding from a source package is just source nothing built or pre-compiled interim product. So source = text files + icons. Yours don't count as source for me. Matthew I tried out the Racket | Source version, which took about one Matthew minute to download (83 MB), about 3-4 minutes for `configure' Matthew plus `make', and about 40 seconds for `make install'. After `make Matthew install', DrRacket was ready to go, and all documentation (for Matthew the main distribution) was available. Yes but my source package is 16 MB with xz compression and circa 21 MB when I package it as tgz. Surely they are smaller than your packages. That also means in the future I would expect a source only package to be available just like it is currently for the 5.3.5 release. -- o.o.o o_o__o _o ,_o o_ | `|' (|))'),' ` |( ' (, ,( )| ' ( ) [ ] [ ]\ / \/ \/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Sat, 20 Jul 2013 17:12:26 +0200, Togan Muftuoglu wrote: On Fri, 19 Jul 2013 17:43:42 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew The documentation directory and collection directory should be Matthew configurable, now. Looks like but I still have problems with the build process as directory contents are not copied to the destinations. The share, doc, and etc directories will be empty/missing for a core build, so that's as expected. (But config vs. etc was a bug that now should be fixed.) Matthew The label on the Source snapshots really should say something Matthew like kernel in source form, plus pre-built packages and Matthew documentation. The Minimal Racket variant doesn't have any Matthew packages, but it has the core collections pre-built, and Matthew installing a package from the main distribution gets the package Matthew in pre-built form from the snapshot site. Sorry my understanding from a source package is just source nothing built or pre-compiled interim product. So source = text files + icons. Yours don't count as source for me. Yes, I can understand why they may not be what you want. They're intended for users who want a complete install that's as fast as possible on a platform where no pre-built executables are already available. That also means in the future I would expect a source only package to be available just like it is currently for the 5.3.5 release. Well, assembling a set of package sources is a kind of interim product --- as long as the assembled set is non-empty, and especially if it's something analogous to v5.3.5. But I think I understand what you mean, and we're just a couple of steps away, now. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
The latest snapshot page includes plain-source options: http://www.cs.utah.edu/plt/snapshots/ The reason for having both Minimal Racket | Source and Minimal Racket | Source + built packages isn't obvious, given that Minimal Racket doesn't include any packages --- but there is a difference (and some future version of the web page will explain): * The + build package variant includes pre-built core collections matching the pre-built packages. When you use `raco pkg install gui', for example, the bytecode and documentation in the downloaded package can be used without rebuilding. * The plain-source version includes no pre-built bytecode, and when you build it yourself, the result will be different than the one used to create pre-built packages (i.e., the bytecode files vary due to effects like `eq?'-hashing). Consequently, when you use `raco pkg install gui', then the bytecode and documentation of the gui package will be rebuilt, even though you're using a catalog server that provides built packages. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Fri, 19 Jul 2013 07:37:13 +0200, Togan Muftuoglu wrote: On Thu, 18 Jul 2013 17:07:38 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew At Fri, 19 Jul 2013 00:48:10 +0200, Togan Muftuoglu wrote: 1. configure and Makefile should allow docdir parameter given at as an arg [...] 2. collects path should be allowed for another location ie. [...] Matthew I'll work on those. Thanks Finally currently build system can't complete the install stage ./racketcgc -cu ./collects-path.rkt \ /home/abuild/rpmbuild/BUILDROOT/racket-5.6.0-0.x86_64/usr/lib64/racket/starter \ /usr/lib64/racket/collects Matthew Is this from a generated Makefile, or it is from some other Matthew script? That is from the generated Makefile. I use the racket/src/configure to generate the Makefile I'm missing something, then. The source Makefile.in says @RUN_RACKET_CGC@ -cu $(srcdir)/collects-path.rkt $(DESTDIR)$(libpltdir)/starter@EXE_SUFFIX@ @COLLECTS_PATH@ @CONFIG_PATH@ and I don't see how `@CONFIG_PATH@' could turn out to be empty. Can you send me the generated racket/Makefile? Matthew The collects-path.rkt script now expects a second path, with is Matthew the configuration directory path to embed in the executable. Is it necessary the configuration directory path should be embed in the executable. Why can't it be set at load time similar to Emacs init file concept I'm not sure I understand the question, but the configuration directory is where Racket finds config.rktd, which in turn describes the location of various other directories (i.e., the ones that you want to configure). The content of config.rktd used to be implemented as a module, and so the configuration resided inside the collection directory. For various reasons, that has not worked well, so (while rearranging things anyway for packages) we moved configuration out of the collects tree and into an etc configuration directory. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
The documentation directory and collection directory should be configurable, now. Besides starting from the git repository, you could also try out the new source snapshot: http://www.cs.utah.edu/plt/snapshots/ The label on the Source snapshots really should say something like kernel in source form, plus pre-built packages and documentation. The Minimal Racket variant doesn't have any packages, but it has the core collections pre-built, and installing a package from the main distribution gets the package in pre-built form from the snapshot site. I tried out the Racket | Source version, which took about one minute to download (83 MB), about 3-4 minutes for `configure' plus `make', and about 40 seconds for `make install'. After `make install', DrRacket was ready to go, and all documentation (for the main distribution) was available. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Wed, 17 Jul 2013 19:52:21 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew I think the new system is as ready as it's going to get without Matthew further feedback, and my guess is that the problem hasn't been Matthew fixed. Can you check with the latest? When I check the current HEAD tag of the master this is what I get. Is this what it should be if not can it be fixed so it reflects reality? ~/devel/git-sources/racket $ git describe --tags HEAD v5.0.1-12863-g3c0b799 Togan o.o.o o_o__o _o ,_o o_ | `|' (|))'),' ` |( ' (, ,( )| ' ( ) [ ] [ ]\ / \/ \/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Thu, Jul 18, 2013 at 04:17:10PM +0200, Togan Muftuoglu wrote: I guess it depends on how one works. When there is no release or I want to package a git version of the project. I need to put a version number in the package spec file, that would make it possible to upgrade or downgrade without breaking the rpm database (I guess that would be the case for deb packages). FWIW, in Debian, we have a little script[0] to help package one of the nightly snapshots. [0]: http://anonscm.debian.org/gitweb/?p=collab-maint/racket.git;a=blob;f=debian/fetch-snapshot.sh;hb=HEAD Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On 07/13/2013 12:56 PM, Matthew Flatt wrote: Here's a big-picture update of where we are in the new package system and the conversion of the Racket distribution to use packages. This message covers [lots of awesome stuff]... Thanks a ton for the update and clarifications, Matthew. I have one question. I maintain 3 collections that will become ring-0 packages. What should I (and others like me) be doing right now in response to the Big Package Shift? Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Thu, 18 Jul 2013 11:44:41 -0600, Neil Toronto wrote: I maintain 3 collections that will become ring-0 packages. What should I (and others like me) be doing right now in response to the Big Package Shift? For packages that are currently in the main Racket repo, then there's nothing in particular to do. If you'd like, you can split (into -lib, -doc, etc., if that seems worthwhile) or otherwise adjust your packages. If your packages are not currently in the main Racket repo, and if your packages are *not* meant to work with v5.3.6 and earlier, then it would be a good idea to update the dependencies. If you packages are meant to work with v5.3.6, however, then maybe there's nothing to do until we sort out a way to write dependencies that work with both the new organization and v5.3.6 (which will probably take a few more days). _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Wed, 17 Jul 2013 19:52:21 -0600, Matthew Flatt
mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said:
Matthew At Mon, 15 Jul 2013 23:17:08 +0200, Togan Muftuoglu wrote:
Maybe I have missed it but is there, or will there be a documentation
showing the dependency of packages. Like package B requires A C and
recommends F.
Matthew We'll need documentation to say which package provides a given
Matthew library.
Matthew I don't anticipate documentation for a package that says which
Matthew other packages it depends on, because that seems like an
Matthew implementation detail of the package. Similarly, the
Matthew documentation for a library does not specify what other libraries
Matthew it imports --- only the bindings that the library provides.
As a side note I have a patch that puts all generated documentation to
/usr/share/doc/packages as the Makefile 5.3.5 (also the previous ones)
do not honor the command line given parameters to the make command. I
can send the patch (which is trivial anyway) but I guess the when the
system will be ready the whole Makefile will be different.
Matthew I think the new system is as ready as it's going to get without
Matthew further feedback, and my guess is that the problem hasn't been
Matthew fixed. Can you check with the latest?
I have some issues compared to 5.3.5 where it was easy to fix. This is not the
case with the current git HEAD
1. configure and Makefile should allow docdir parameter given at as an arg
generated documentation (ie. html pdf) and other docs (README License etc)
should be located in for opensuse /usr/share/doc/packages/PACKAGE-NAME since
documention can be packaged separately and the end user has the option of not
installing it/them.
2. collects path should be allowed for another location ie.
/usr/lib/racked/collects for opensuse should be /usr/share/racket/collects
Finally currently build system can't complete the install stage
./racketcgc -cu ./collects-path.rkt \
/home/abuild/rpmbuild/BUILDROOT/racket-5.6.0-0.x86_64/usr/lib64/racket/starter
\
/usr/lib64/racket/collects
vector-ref: index is out of range
index: 2
valid range: [0, 1]
vector:
'#(/home/abuild/rpmbuild/BUILDROOT/racket-5.6.0-0.x86_64/usr/lib64/racket/starter
/usr/lib64/racket/collects)
So at the moment I haven't been able to create a rpm package
the configure options are
%configure --enable-shared \
--disable-static --docdir=%_defaultdocdir/%name
--disable-strip --enable-places
--enable-lt=/usr/bin/libtool
make
make install DESTDIR=/BUILDROOT/%{name}-%{version}-%{release}.x86_64
Thanks
Togan
--
o.o.o o_o__o _o ,_o o_
| `|' (|))'),' ` |( ' (, ,( )| '
( ) [ ] [ ]\ / \/ \/
_
Racket Developers list:
http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Fri, 19 Jul 2013 00:48:10 +0200, Togan Muftuoglu wrote: 1. configure and Makefile should allow docdir parameter given at as an arg [...] 2. collects path should be allowed for another location ie. [...] I'll work on those. Finally currently build system can't complete the install stage ./racketcgc -cu ./collects-path.rkt \ /home/abuild/rpmbuild/BUILDROOT/racket-5.6.0-0.x86_64/usr/lib64/racket/starter \ /usr/lib64/racket/collects Is this from a generated Makefile, or it is from some other script? The collects-path.rkt script now expects a second path, with is the configuration directory path to embed in the executable. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Thu, Jul 18, 2013 at 05:07:38PM -0600, Matthew Flatt wrote: At Fri, 19 Jul 2013 00:48:10 +0200, Togan Muftuoglu wrote: 1. configure and Makefile should allow docdir parameter given at as an arg [...] 2. collects path should be allowed for another location ie. [...] I'll work on those. David or I probably should have brought up the second point earlier. We've been carrying a patch[0] in Debian to do that for a while now, although it's just changing one hard-coded path with another. [0]: http://anonscm.debian.org/gitweb/?p=collab-maint/racket.git;a=blob;f=debian/fetch-snapshot.sh;hb=HEAD -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Thu, 18 Jul 2013 19:51:08 -0400, James McCoy jamessan-8fiuurrzop0dnm+yrof...@public.gmane.org said: James On Thu, Jul 18, 2013 at 05:07:38PM -0600, Matthew Flatt wrote: At Fri, 19 Jul 2013 00:48:10 +0200, Togan Muftuoglu wrote: 1. configure and Makefile should allow docdir parameter given at as an arg [...] 2. collects path should be allowed for another location ie. [...] I'll work on those. James David or I probably should have brought up the second point James earlier. We've been carrying a patch[0] in Debian to do that for a James while now, although it's just changing one hard-coded path with James another. Well, I have a patch that is similar to debian also with the addition of the doc location fix. But the main issues are not these two -- o.o.o o_o__o _o ,_o o_ | `|' (|))'),' ` |( ' (, ,( )| ' ( ) [ ] [ ]\ / \/ \/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Thu, 18 Jul 2013 17:07:38 -0600, Matthew Flatt mflatt-sDh8Nw2yj/+vc3sceru...@public.gmane.org said: Matthew At Fri, 19 Jul 2013 00:48:10 +0200, Togan Muftuoglu wrote: 1. configure and Makefile should allow docdir parameter given at as an arg [...] 2. collects path should be allowed for another location ie. [...] Matthew I'll work on those. Thanks Finally currently build system can't complete the install stage ./racketcgc -cu ./collects-path.rkt \ /home/abuild/rpmbuild/BUILDROOT/racket-5.6.0-0.x86_64/usr/lib64/racket/starter \ /usr/lib64/racket/collects Matthew Is this from a generated Makefile, or it is from some other Matthew script? That is from the generated Makefile. I use the racket/src/configure to generate the Makefile Matthew The collects-path.rkt script now expects a second path, with is Matthew the configuration directory path to embed in the executable. Is it necessary the configuration directory path should be embed in the executable. Why can't it be set at load time similar to Emacs init file concept -- o.o.o o_o__o _o ,_o o_ | `|' (|))'),' ` |( ' (, ,( )| ' ( ) [ ] [ ]\ / \/ \/ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Mon, 15 Jul 2013 23:17:08 +0200, Togan Muftuoglu wrote: Maybe I have missed it but is there, or will there be a documentation showing the dependency of packages. Like package B requires A C and recommends F. We'll need documentation to say which package provides a given library. I don't anticipate documentation for a package that says which other packages it depends on, because that seems like an implementation detail of the package. Similarly, the documentation for a library does not specify what other libraries it imports --- only the bindings that the library provides. As a side note I have a patch that puts all generated documentation to /usr/share/doc/packages as the Makefile 5.3.5 (also the previous ones) do not honor the command line given parameters to the make command. I can send the patch (which is trivial anyway) but I guess the when the system will be ready the whole Makefile will be different. I think the new system is as ready as it's going to get without further feedback, and my guess is that the problem hasn't been fixed. Can you check with the latest? Thanks! Matthew _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Mon, Jul 15, 2013 at 11:39 AM, Matthew Flatt mfl...@cs.utah.edu wrote: 3(a) Speaking of which, I think there is some backlog of pull requests on GitHub. Would it be simpler to to accept any more of these before the source layout universe changes, or too much to deal with so punt until later? (I don't know either way, just wanted to point it out.) It doesn't matter to me. Pull requests based on a recent HEAD are obviously easier for me to deal with, but I can sort requests that are based on old file locations, too. As the person who deals with GitHub pull requests most, I agree here. Of course, I'm not the only (or even main) person who deals with pull requests, so others will have to speak up if they have different opinions. I think that major thing Greg points out is that there are a number of PRs that need review, and hopefully people can look at them. I've tried to nag people on GitHub about this -- would it be more helpful to do this by email? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Sun, 14 Jul 2013 09:43:13 -0400, Sam Tobin-Hochstadt wrote: On Sun, Jul 14, 2013 at 9:29 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 14 Jul 2013 09:02:28 -0400, Sam Tobin-Hochstadt wrote: But when you run `raco pkg install' or `raco pkg update', then the package details are not necessarily determined by pkg.racket-lang.org. The package might be downloaded as pre-built from someplace suitable to your specific installation. The term package catalog is used in the quoted text above to the refer to the server that `raco pkg install' consults first. The (very) speculative part is that the Racket and Minimal Racket installations might check different places first. But both kinds of installation would definitely include pkg.racket-lang.org in the set of catalogs that they check. Ok, that makes sense. Which packages are you imagining would be served from this catalog? Just the ones currently in the Racket distribution? Everything that's in ring 0 on pkg.racket-lang.org? Some other set? Ring 0 (for PLT's distribution). Finally, can you say anything about whether you anticipate the release process changing? Would it be possible to decouple the core Racket releases from, say, the Typed Racket releases, with a release of the whole system bundling specific versions of everything? I expect that we'll want to do that, but I'm not sure it will work well for all users. The idea behind the Racket versus Minimal Racket package-catalog speculation was that people might opt into decoupled releases by using the Minimal Racket distribution. Just to be sure we're on the same page here, I'm thinking of something like Gnome or the Haskell Platform, where there is a big release which is what most people install containing lots of little packages. Which users do you think this might not work for, and why? Well, I'm not sure. My sense is that updates to main-distribution packages could create trouble for novice users. Maybe that's not the case, or maybe it will be the case only until we get our package infrastructure refined. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Sun, 14 Jul 2013 18:02:11 -0400, Greg Hendershott wrote: 1. Racket has a wonderful story about simple installation. [..] For many users, a monolithic(ish) simple install will remain a wonderful thing. As best I understand, the proposal isn't to get rid of that, instead it's to supplement it with more options. Yes. If so, (a) great! And (b), this may still be tricky because we wouldn't want that _message_ to get obscured when announcing the new, more sophisticated thing. Right, we'll have to pay attention to that. 3(a) Speaking of which, I think there is some backlog of pull requests on GitHub. Would it be simpler to to accept any more of these before the source layout universe changes, or too much to deal with so punt until later? (I don't know either way, just wanted to point it out.) It doesn't matter to me. Pull requests based on a recent HEAD are obviously easier for me to deal with, but I can sort requests that are based on old file locations, too. Of course, I'm not the only (or even main) person who deals with pull requests, so others will have to speak up if they have different opinions. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Mon, 15 Jul 2013 09:34:00 -0600, Matthew Flatt mfl...@cs.utah.edu said: Matthew At Sun, 14 Jul 2013 15:59:28 +0200, tog...@opensuse.org wrote: On Sun, 14 Jul 2013 07:00:14 -0600, Matthew Flatt mfl...@cs.utah.edu said: Matthew Longer term, I think that OS-level packages/ports should probably Matthew reflect a minimal Racket installation, and then further Racket Matthew packages would be installed via the Racket package system. Well, I would argue the other way around, as the whole package system would have been prepared for the distribution in mind, for example I build the package with shared-libraries, and avoding any static library, in addition to not to use bundled software ie. libffi. This makes my life as the maintainer of the package easier as any possible bug/security fix would be easier. Matthew I agree that all the things you list should be part of any Matthew OS-specific packaging of Racket. I think all of those details are Matthew part of the core build, so they would be consistent with a Matthew Minimal Racket package. Maybe I have missed it but is there, or will there be a documentation showing the dependency of packages. Like package B requires A C and recommends F. Currently the opensuse packages have a racket package and separate packages for drracket, webserver, slideshow. As a side note I have a patch that puts all generated documentation to /usr/share/doc/packages as the Makefile 5.3.5 (also the previous ones) do not honor the command line given parameters to the make command. I can send the patch (which is trivial anyway) but I guess the when the system will be ready the whole Makefile will be different. Having said that the idea sounds more like the Emacs elpa system, and the user has the option to either download the distro provided packages or elpa versions. So in a effect racket goes the similar way. Matthew Yes, that sounds right. Ok then what is the current default install directory for the user downloaded packages ? It should be user's home directory by default as it is with elpa and its derivative melpa _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
Matthew Flatt wrote at 07/13/2013 02:56 PM: Others seem overwhelmed by the details, unsure of how it will all work out, and disconcerted by conflicting messages from others who seem to understand the issues. BTW, I don't know whether I'm involved in anyone being disconcerted. If I am, please let me clarify that I agree that this effort looks like a win for development of variations on core Racket, and for packaging of shrinkwrapped apps built with Racket. (Praisecondolences to those people doing a lot of non-fun work to achieve those goals.) In addition to those goals, I also had some research and advocacy goals that are affected by the package system model. Now is not the time to get into that, but perhaps we can discuss at a later date, as the model evolves in subsequent versions of Racket. Much secondarily, there are lots of little details, about which different people will feel differently. I suspect we'll all quickly get accustomed to the little details, and if any little detail becomes ornery for lots of people, it could be refined. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Sun, 14 Jul 2013 02:54:06 +0200, Juan Francisco Cantero Hurtado wrote: On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? This was not been part of the plan. Now that you ask, though, I see how it makes sense to package the core source together with package sources for a given set of packages --- including the main-distribution package, for a site that distributes main-distribution installers. So, yes, we'll do that. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
Thanks! (For one, I found the From Back There to Here section particularly helpful.) On Sat, Jul 13, 2013 at 1:56 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Here's a big-picture update of where we are in the new package system and the conversion of the Racket distribution to use packages. This message covers - how I see things working after the package system and reorganization is done, and a report on what pieces are still missing to reach that vision; - a look at how we got to our current design/reorganization choices and whether we're choosing the right place; and - speculation on why the package changes have been so difficult to implement. All of that makes it a long message (sorry!), but I hope this message is useful to bring us more in sync. A Package-Based Racket -- Let's take a look at how you'll do various things in the new package-based Racket world. (There's no new information here, and parts marked with [guess] are especially speculative. Still, some details may be clearer than in earlier accounts, now that much of it is implemented, and I think a comprehensive review may be useful.) ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. The blue button might also provide the option of Minimal Racket installers, which gives you something that's a small as we can make it and still provides command-line `raco pkg'. ** Downloading installers from other distributors There are all sorts of reasons that the main distribution from PLT might not fit the needs of some group. Maybe the release cycle is too long or at the wrong time. Maybe it includes much too much, much too little, or almost the right amount but missing a crucial package. Maybe the group wants something almost minimal, but still with a graphical package manager. Maybe some group uses a platform for which PLT does not provide an installer. For many of those groups, using a Minimal Racket installer plus selective package installations will do the trick. For others, creating a special set of installers might be worthwhile, but there are too many reasons and too many permutations for PLT to provide installers that cover all of them. Fortunately, anyone can build a set of installers and put them on a web page, and we make it as easy as possible to build a set of installers that start with a given set of packages. PLT could host a web page or wiki that points to other distributors. PLT might even be able to provide an automated service that generates a set of installers for a basic set of platforms. ** Compiling a release from source In addition to installers, a download site can provide a source-code option (not specific to any platform, unlike the current source packages), which would mainly be used for building Racket on additional platforms. This option is mostly a snapshot of the source-code repository for the core, but it includes a pre-built collects tree (see technical detail, below) and a default configuration that points back to the distributor's site for pre-built packages. ** Adding or upgrading supported packages In much the same way that you can easily install a set of supported packages on your current OS, you'll be able to easily install a set of packages that are supported by your distributor. Those packages are pre-built, so they install quickly, along with any included documentation. Depending on the distributor and installer, packages might be downloaded and installed in binary form, which means that tests and source code (for libraries and documentation) are omitted from the package. PLT seems unlikely to provide such installers in the near future. The default package scope configured by a distribution tends to be user, which means that packages are installed in a user-specific location. Package updates can be made available by distributors for whatever reason and on whatever timetable see they fit. If your distribution is from PLT, then the supported packages are called ring-0 packages. Ring-0 packages include contributions from third parties (i.e., not just packages implemented by PLT) that are vetted and regularly tested by PLT. [Guess:] The Racket and Minimal Racket distributions might point to different pre-built package catalogs. Possibly, the Racket catalog never updates packages that were included in the installer (on the grounds that the user may not have write permission to the install), while the Minimal Racket catalog includes more frequent updates for bug fixes (on the grounds that the user can update any installed package). A distributor doesn't necessarily have to provide its own package catalog. It can instead supply an
Re: [racket-dev] package-system update
At Sun, 14 Jul 2013 02:54:06 +0200, Juan Francisco Cantero Hurtado wrote: On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? To clarify (because I now realize this may not have been apparent to others), you have in mind delivering Racket's main distribution as an OpenBSD port, right? At Sun, 14 Jul 2013 06:00:17 -0600, Matthew Flatt wrote: This was not been part of the plan. Now that you ask, though, I see how it makes sense to package the core source together with package sources for a given set of packages --- including the main-distribution package, for a site that distributes main-distribution installers. Longer term, I think that OS-level packages/ports should probably reflect a minimal Racket installation, and then further Racket packages would be installed via the Racket package system. But I can also see how a main Racket distribution package/port that resides completely within the OS's system could also make sense, especially in the short term. A core+package source tarball should make that easier. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
First, thanks for the very informative update. On Sat, Jul 13, 2013 at 2:56 PM, Matthew Flatt mfl...@cs.utah.edu wrote: [Guess:] The Racket and Minimal Racket distributions might point to different pre-built package catalogs. Possibly, the Racket catalog never updates packages that were included in the installer (on the grounds that the user may not have write permission to the install), while the Minimal Racket catalog includes more frequent updates for bug fixes (on the grounds that the user can update any installed package). I'm not 100% sure what you mean about different pre-built package catalogs but I definitely feel that we should just have one site like `pkg.racket-lang.org` where people go to see what packages they might install in their Racket installation. This comes back to the point you make below about how technology, here the package server, can keep a distributed community together. ** Using the bleeding edge as a PLT developer As a convenience to PLT developers, who tend to work on a particular set of packages, there is an alternate way of working on the bleeding edge (which anyone can use, if they prefer). [Guess #1:] Instead of cloning the core Racket repo, clone a main distribution repo that has the core Racket repo as a submodule, plus git submodules for each of the packages that are dependencies of main-distribution. In other words, you get something that looks like the current Racket repo, but that uses git submodules. [Guess #2:] Instead of cloning the core Racket repo from GitHub, you clone from the main distribution repository, just like now. In addition to being mirrored to GitHub directly, individual parts of the main distribution repo are mirrored as GitHub repositories, and the mirrors are the ones that pkg.racket-lang.org references. Guess #2 seems to have a lot more complicated working parts, and it seems like it would prevent us from actually using github for the all the repositories -- ie, that we'd have to keep running our own git server. Finally, can you say anything about whether you anticipate the release process changing? Would it be possible to decouple the core Racket releases from, say, the Typed Racket releases, with a release of the whole system bundling specific versions of everything? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
At Sun, 14 Jul 2013 09:02:28 -0400, Sam Tobin-Hochstadt wrote: First, thanks for the very informative update. On Sat, Jul 13, 2013 at 2:56 PM, Matthew Flatt mfl...@cs.utah.edu wrote: [Guess:] The Racket and Minimal Racket distributions might point to different pre-built package catalogs. Possibly, the Racket catalog never updates packages that were included in the installer (on the grounds that the user may not have write permission to the install), while the Minimal Racket catalog includes more frequent updates for bug fixes (on the grounds that the user can update any installed package). I'm not 100% sure what you mean about different pre-built package catalogs but I definitely feel that we should just have one site like `pkg.racket-lang.org` where people go to see what packages they might install in their Racket installation. This comes back to the point you make below about how technology, here the package server, can keep a distributed community together. Yes, pkg-racket-lang.org is where you go to find out what packages are available. But when you run `raco pkg install' or `raco pkg update', then the package details are not necessarily determined by pkg.racket-lang.org. The package might be downloaded as pre-built from someplace suitable to your specific installation. The term package catalog is used in the quoted text above to the refer to the server that `raco pkg install' consults first. The (very) speculative part is that the Racket and Minimal Racket installations might check different places first. But both kinds of installation would definitely include pkg.racket-lang.org in the set of catalogs that they check. Finally, can you say anything about whether you anticipate the release process changing? Would it be possible to decouple the core Racket releases from, say, the Typed Racket releases, with a release of the whole system bundling specific versions of everything? I expect that we'll want to do that, but I'm not sure it will work well for all users. The idea behind the Racket versus Minimal Racket package-catalog speculation was that people might opt into decoupled releases by using the Minimal Racket distribution. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Sun, Jul 14, 2013 at 9:29 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 14 Jul 2013 09:02:28 -0400, Sam Tobin-Hochstadt wrote: But when you run `raco pkg install' or `raco pkg update', then the package details are not necessarily determined by pkg.racket-lang.org. The package might be downloaded as pre-built from someplace suitable to your specific installation. The term package catalog is used in the quoted text above to the refer to the server that `raco pkg install' consults first. The (very) speculative part is that the Racket and Minimal Racket installations might check different places first. But both kinds of installation would definitely include pkg.racket-lang.org in the set of catalogs that they check. Ok, that makes sense. Which packages are you imagining would be served from this catalog? Just the ones currently in the Racket distribution? Everything that's in ring 0 on pkg.racket-lang.org? Some other set? Finally, can you say anything about whether you anticipate the release process changing? Would it be possible to decouple the core Racket releases from, say, the Typed Racket releases, with a release of the whole system bundling specific versions of everything? I expect that we'll want to do that, but I'm not sure it will work well for all users. The idea behind the Racket versus Minimal Racket package-catalog speculation was that people might opt into decoupled releases by using the Minimal Racket distribution. Just to be sure we're on the same page here, I'm thinking of something like Gnome or the Haskell Platform, where there is a big release which is what most people install containing lots of little packages. Which users do you think this might not work for, and why? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
See below Sent from my iPhone On Jul 14, 2013, at 8:03 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: First, thanks for the very informative update. On Sat, Jul 13, 2013 at 2:56 PM, Matthew Flatt mfl...@cs.utah.edu wrote: [Guess:] The Racket and Minimal Racket distributions might point to different pre-built package catalogs. Possibly, the Racket catalog never updates packages that were included in the installer (on the grounds that the user may not have write permission to the install), while the Minimal Racket catalog includes more frequent updates for bug fixes (on the grounds that the user can update any installed package). I'm not 100% sure what you mean about different pre-built package catalogs but I definitely feel that we should just have one site like `pkg.racket-lang.org` where people go to see what packages they might install in their Racket installation. This comes back to the point you make below about how technology, here the package server, can keep a distributed community together. The ability to easily replace the server will be useful for people building frozen services where a piece of software wants to ensure that no updates could happen. ** Using the bleeding edge as a PLT developer As a convenience to PLT developers, who tend to work on a particular set of packages, there is an alternate way of working on the bleeding edge (which anyone can use, if they prefer). [Guess #1:] Instead of cloning the core Racket repo, clone a main distribution repo that has the core Racket repo as a submodule, plus git submodules for each of the packages that are dependencies of main-distribution. In other words, you get something that looks like the current Racket repo, but that uses git submodules. [Guess #2:] Instead of cloning the core Racket repo from GitHub, you clone from the main distribution repository, just like now. In addition to being mirrored to GitHub directly, individual parts of the main distribution repo are mirrored as GitHub repositories, and the mirrors are the ones that pkg.racket-lang.org references. Guess #2 seems to have a lot more complicated working parts, and it seems like it would prevent us from actually using github for the all the repositories -- ie, that we'd have to keep running our own git server. Finally, can you say anything about whether you anticipate the release process changing? Would it be possible to decouple the core Racket releases from, say, the Typed Racket releases, with a release of the whole system bundling specific versions of everything? Sam _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On Sun, 14 Jul 2013 07:00:14 -0600, Matthew Flatt mfl...@cs.utah.edu said: At Sun, 14 Jul 2013 02:54:06 +0200, Juan Francisco Cantero Hurtado wrote: On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? Matthew To clarify (because I now realize this may not have been apparent Matthew to others), you have in mind delivering Racket's main Matthew distribution as an OpenBSD port, right? Just to add myself to the conversation, I am package maintainer for openSUSE and racket has been in the opensuse repos for some time now. Also with the next release it will also be part of the main opensuse distribution. Currently, the package is built for openSUSE 12.2 12.3 and Factory versions Matthew At Sun, 14 Jul 2013 06:00:17 -0600, Matthew Flatt wrote: This was not been part of the plan. Now that you ask, though, I see how it makes sense to package the core source together with package sources for a given set of packages --- including the main-distribution package, for a site that distributes main-distribution installers. Matthew Longer term, I think that OS-level packages/ports should probably Matthew reflect a minimal Racket installation, and then further Racket Matthew packages would be installed via the Racket package system. Well, I would argue the other way around, as the whole package system would have been prepared for the distribution in mind, for example I build the package with shared-libraries, and avoding any static library, in addition to not to use bundled software ie. libffi. This makes my life as the maintainer of the package easier as any possible bug/security fix would be easier. Having said that the idea sounds more like the Emacs elpa system, and the user has the option to either download the distro provided packages or elpa versions. So in a effect racket goes the similar way. Matthew But I can also see how a main Racket distribution package/port Matthew that resides completely within the OS's system could also make Matthew sense, especially in the short term. A core+package source Matthew tarball should make that easier. That would be make the package maintaining easy. Thanks _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On 07/14/13 15:00, Matthew Flatt wrote: At Sun, 14 Jul 2013 02:54:06 +0200, Juan Francisco Cantero Hurtado wrote: On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? To clarify (because I now realize this may not have been apparent to others), you have in mind delivering Racket's main distribution as an OpenBSD port, right? I'm not sure yet. I have three options: - One big port with one big tarball. Like the actual port. Easiest in short term, probably a bad choice in the long term. - One port for the racket core + one port for each package from the PLT distro. I should create a port-module ( http://mdoc.su/o/port-modules ) for raco ports. Something similar to the port module of python or ruby. A lot of work for me. - Just one port for racket core. It's my favorite. At Sun, 14 Jul 2013 06:00:17 -0600, Matthew Flatt wrote: This was not been part of the plan. Now that you ask, though, I see how it makes sense to package the core source together with package sources for a given set of packages --- including the main-distribution package, for a site that distributes main-distribution installers. Longer term, I think that OS-level packages/ports should probably reflect a minimal Racket installation, and then further Racket packages would be installed via the Racket package system. But I can also see how a main Racket distribution package/port that resides completely within the OS's system could also make sense, especially in the short term. A core+package source tarball should make that easier. I'm worried about something. What will be the policy related to the bugfix releases of the packages?. Now, if some part of racket is broken on OpenBSD, I temporally patch the port and wait the next release of racket. If I decide go with the third option (only maintain the port of racket core), racket team will release quick bugfix updates to packages without wait to the next release of racket core?. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] package-system update
On 07/13/13 20:56, Matthew Flatt wrote: [...] ** Downloading release installers from PLT The www.racket-lang.org site's big blue button will provide the same installers that it does now, at least by default. That is, the content provided by the installer --- DrRacket, teaching languages, etc. --- will be pretty much the same as now. Will be also available a big tarball with the source and all batteries included, like the actual unix source?. Will be possible to compile a full distro of racket with the usual configure make make install? [...] From Here to There -- The snapshot site http://www.cs.utah.edu/plt/snapshots/ (Now I understand that you said me about 5.3.900 in the bug of raco pkg, I was confusing the development version with an old X.Y.Z.900 release :) ) _ Racket Developers list: http://lists.racket-lang.org/dev
