Re: [racket-dev] Installing subsets of Racket

2013-09-24 Thread Laurent
Thanks for the info.
Binaries may still be good when one wants to install a package only for a
single purpose.



On Tue, Sep 24, 2013 at 12:50 AM, Matthew Flatt mfl...@cs.utah.edu wrote:

 Although packages are not currently distributed in binary form, you can
 install built packages (as available from a snapshot site) in binary
 mode by supplying the `--binary' flag to `raco pkg install'.

 For example, if you start with a Minimal Racket build from

   http://www.cs.utah.edu/plt/snapshots/

 then install it on Mac OS X (64-bit), it starts with a footprint of
 about 30 MB.

 Using

  bin/raco pkg install -i --binary images

 installs about 40 packages to bring the total footprint to about 70 MB.

 In contrast, using

  bin/raco pkg install -i images

 installs about 95 packages to bring the total footprint to about 260
 MB.

 Fewer packages are installed in binary mode because build dependencies
 are pruned from each package as it is converted (on download) from
 built to binary.

 The binary versus built distinction doesn't automatically exclude
 documentation. The 40-ish packages installed for images includes
 images-doc, because the images package is meant to imply both
 images-lib and images-doc. Little other documentation is installed,
 however, because other documentation is mostly needed only to build the
 images documentation.

 The smallest installation with the images libraries is

  bin/raco pkg install -i --binary images-lib

 which installs about 30 packages to bring the total footprint to about
 55 MB.

 Then again, sticking with built mode as

  bin/raco pkg install -i images-lib

 installs the same 30-ish packages with a footprint of 65 MB, which
 illustrates that the savings from `--binary' are almost all from
 reducing dependencies (and not about omitting source).

 So, `--binary` is available and can help, but it's an indirect way of
 reducing dependencies. Improved support for generating, installing, and
 depending on -lib variants might be better in the long run --- but I
 think we don't know how to do that, yet.

 At Mon, 16 Sep 2013 09:04:49 -0600, Jay McCarthy wrote:
  Hi Laurent,
 
  I think that the solution to this are binary builds versions of
  a package that only have the bytecode and documentation.
 
  We're a bit behind on binary builds, because when they were discussed
  for the main repository [1] they were rejected. I hope to be able to
  still provide them for ring-0 packages through the results of DrDr
  running tests (and thus compiling) on those packages, but it's in the
  future.
 
  The result would be that when you installed a package in binary
  form, you would only get the deps and not the build-deps. (And
  you'd probably get those in binary form too.)
 
  Jay
 
  1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html
 
  On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com
 wrote:
   Hi,
  
   (this is not a complain, just an inquiry)
  
   While installing Racket on a small server, I wanted to avoid
 installing gui
   and doc related libraries.
   The minimal install was great!
  
   Then I wanted to install a package of my own (the aptly named
 bazaar),
   which requires images and other gui libs (which I actually would not
 use
   on the server), among other things, but no doc
  
   But the images package draws racket-doc and gui-doc dependencies,
 which in
   turn draws practically all of Racket. And it then takes a much longer
 time
   for `raco setup` to do its job that I had hoped for.
  
   Certainly, this can be resolved by splitting images and bazaar
 into lib,
   gui and docs packages, but I foresee another problem:
   It's difficult to enforce such a split for third-party libraries, as
 it puts
   the burden on the user.
   And the first package like that to be installed will again draw all of
   Racket dependencies.
  
   This is probably not a trivial matter, but what can be done about this?
  
   My dream would be that gui and doc dependencies are never triggered,
 without
   preventing the packages I actually use to be downloaded, but I don't
 know
   how this could actually be ensured without a good amount of magic.
  
   Merely preventing downloads does not sound like a good option though.
  
   I bet you've already discussed this far and wide, so are there any
 plans?
  
   Laurent
  
   _
 Racket Developers list:
 http://lists.racket-lang.org/dev
  
 
 
 
  --
  Jay McCarthy j...@cs.byu.edu
  Assistant Professor / Brigham Young University
  http://faculty.cs.byu.edu/~jay
 
  The glory of God is Intelligence - DC 93
  _
Racket Developers list:
http://lists.racket-lang.org/dev

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


Re: [racket-dev] Installing subsets of Racket

2013-09-23 Thread Matthew Flatt
Although packages are not currently distributed in binary form, you can
install built packages (as available from a snapshot site) in binary
mode by supplying the `--binary' flag to `raco pkg install'.

For example, if you start with a Minimal Racket build from

  http://www.cs.utah.edu/plt/snapshots/

then install it on Mac OS X (64-bit), it starts with a footprint of
about 30 MB.

Using

 bin/raco pkg install -i --binary images

installs about 40 packages to bring the total footprint to about 70 MB.

In contrast, using

 bin/raco pkg install -i images

installs about 95 packages to bring the total footprint to about 260
MB.

Fewer packages are installed in binary mode because build dependencies
are pruned from each package as it is converted (on download) from
built to binary.

The binary versus built distinction doesn't automatically exclude
documentation. The 40-ish packages installed for images includes
images-doc, because the images package is meant to imply both
images-lib and images-doc. Little other documentation is installed,
however, because other documentation is mostly needed only to build the
images documentation.

The smallest installation with the images libraries is

 bin/raco pkg install -i --binary images-lib

which installs about 30 packages to bring the total footprint to about
55 MB.

Then again, sticking with built mode as

 bin/raco pkg install -i images-lib

installs the same 30-ish packages with a footprint of 65 MB, which
illustrates that the savings from `--binary' are almost all from
reducing dependencies (and not about omitting source).

So, `--binary` is available and can help, but it's an indirect way of
reducing dependencies. Improved support for generating, installing, and
depending on -lib variants might be better in the long run --- but I
think we don't know how to do that, yet.

At Mon, 16 Sep 2013 09:04:49 -0600, Jay McCarthy wrote:
 Hi Laurent,
 
 I think that the solution to this are binary builds versions of
 a package that only have the bytecode and documentation.
 
 We're a bit behind on binary builds, because when they were discussed
 for the main repository [1] they were rejected. I hope to be able to
 still provide them for ring-0 packages through the results of DrDr
 running tests (and thus compiling) on those packages, but it's in the
 future.
 
 The result would be that when you installed a package in binary
 form, you would only get the deps and not the build-deps. (And
 you'd probably get those in binary form too.)
 
 Jay
 
 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html
 
 On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote:
  Hi,
 
  (this is not a complain, just an inquiry)
 
  While installing Racket on a small server, I wanted to avoid installing gui
  and doc related libraries.
  The minimal install was great!
 
  Then I wanted to install a package of my own (the aptly named bazaar),
  which requires images and other gui libs (which I actually would not use
  on the server), among other things, but no doc
 
  But the images package draws racket-doc and gui-doc dependencies, which in
  turn draws practically all of Racket. And it then takes a much longer time
  for `raco setup` to do its job that I had hoped for.
 
  Certainly, this can be resolved by splitting images and bazaar into lib,
  gui and docs packages, but I foresee another problem:
  It's difficult to enforce such a split for third-party libraries, as it puts
  the burden on the user.
  And the first package like that to be installed will again draw all of
  Racket dependencies.
 
  This is probably not a trivial matter, but what can be done about this?
 
  My dream would be that gui and doc dependencies are never triggered, without
  preventing the packages I actually use to be downloaded, but I don't know
  how this could actually be ensured without a good amount of magic.
 
  Merely preventing downloads does not sound like a good option though.
 
  I bet you've already discussed this far and wide, so are there any plans?
 
  Laurent
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 
 
 
 
 -- 
 Jay McCarthy j...@cs.byu.edu
 Assistant Professor / Brigham Young University
 http://faculty.cs.byu.edu/~jay
 
 The glory of God is Intelligence - DC 93
 _
   Racket Developers list:
   http://lists.racket-lang.org/dev
_
  Racket Developers list:
  http://lists.racket-lang.org/dev


Re: [racket-dev] Installing subsets of Racket

2013-09-16 Thread Jay McCarthy
Hi Laurent,

I think that the solution to this are binary builds versions of
a package that only have the bytecode and documentation.

We're a bit behind on binary builds, because when they were discussed
for the main repository [1] they were rejected. I hope to be able to
still provide them for ring-0 packages through the results of DrDr
running tests (and thus compiling) on those packages, but it's in the
future.

The result would be that when you installed a package in binary
form, you would only get the deps and not the build-deps. (And
you'd probably get those in binary form too.)

Jay

1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html

On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote:
 Hi,

 (this is not a complain, just an inquiry)

 While installing Racket on a small server, I wanted to avoid installing gui
 and doc related libraries.
 The minimal install was great!

 Then I wanted to install a package of my own (the aptly named bazaar),
 which requires images and other gui libs (which I actually would not use
 on the server), among other things, but no doc

 But the images package draws racket-doc and gui-doc dependencies, which in
 turn draws practically all of Racket. And it then takes a much longer time
 for `raco setup` to do its job that I had hoped for.

 Certainly, this can be resolved by splitting images and bazaar into lib,
 gui and docs packages, but I foresee another problem:
 It's difficult to enforce such a split for third-party libraries, as it puts
 the burden on the user.
 And the first package like that to be installed will again draw all of
 Racket dependencies.

 This is probably not a trivial matter, but what can be done about this?

 My dream would be that gui and doc dependencies are never triggered, without
 preventing the packages I actually use to be downloaded, but I don't know
 how this could actually be ensured without a good amount of magic.

 Merely preventing downloads does not sound like a good option though.

 I bet you've already discussed this far and wide, so are there any plans?

 Laurent

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




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

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


Re: [racket-dev] Installing subsets of Racket

2013-09-16 Thread Laurent
great, thanks, that was quick!


On Mon, Sep 16, 2013 at 6:34 PM, Robby Findler
ro...@eecs.northwestern.eduwrote:

 In the meantime, the images pkg is now broken up and images-lib depends
 only on draw-lib (and some unstable stuff), no longer on the full gui
 library or the docs.

 Robby


 On Mon, Sep 16, 2013 at 11:24 AM, Laurent laurent.ors...@gmail.comwrote:

 Sounds good!

 I think as long as it's possible to somehow choose between byte-code and
 source-code packages/distributions, there should not be too much to worry
 about. My server would be very happy with byte-code packages, and my
 desktop with a full source-code Racket.

 Laurent



 On Mon, Sep 16, 2013 at 5:04 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 Hi Laurent,

 I think that the solution to this are binary builds versions of
 a package that only have the bytecode and documentation.

 We're a bit behind on binary builds, because when they were discussed
 for the main repository [1] they were rejected. I hope to be able to
 still provide them for ring-0 packages through the results of DrDr
 running tests (and thus compiling) on those packages, but it's in the
 future.

 The result would be that when you installed a package in binary
 form, you would only get the deps and not the build-deps. (And
 you'd probably get those in binary form too.)

 Jay

 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html

 On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com
 wrote:
  Hi,
 
  (this is not a complain, just an inquiry)
 
  While installing Racket on a small server, I wanted to avoid
 installing gui
  and doc related libraries.
  The minimal install was great!
 
  Then I wanted to install a package of my own (the aptly named
 bazaar),
  which requires images and other gui libs (which I actually would not
 use
  on the server), among other things, but no doc
 
  But the images package draws racket-doc and gui-doc dependencies,
 which in
  turn draws practically all of Racket. And it then takes a much longer
 time
  for `raco setup` to do its job that I had hoped for.
 
  Certainly, this can be resolved by splitting images and bazaar
 into lib,
  gui and docs packages, but I foresee another problem:
  It's difficult to enforce such a split for third-party libraries, as
 it puts
  the burden on the user.
  And the first package like that to be installed will again draw all of
  Racket dependencies.
 
  This is probably not a trivial matter, but what can be done about this?
 
  My dream would be that gui and doc dependencies are never triggered,
 without
  preventing the packages I actually use to be downloaded, but I don't
 know
  how this could actually be ensured without a good amount of magic.
 
  Merely preventing downloads does not sound like a good option though.
 
  I bet you've already discussed this far and wide, so are there any
 plans?
 
  Laurent
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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

 The glory of God is Intelligence - DC 93



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



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


Re: [racket-dev] Installing subsets of Racket

2013-09-16 Thread Robby Findler
In the meantime, the images pkg is now broken up and images-lib depends
only on draw-lib (and some unstable stuff), no longer on the full gui
library or the docs.

Robby


On Mon, Sep 16, 2013 at 11:24 AM, Laurent laurent.ors...@gmail.com wrote:

 Sounds good!

 I think as long as it's possible to somehow choose between byte-code and
 source-code packages/distributions, there should not be too much to worry
 about. My server would be very happy with byte-code packages, and my
 desktop with a full source-code Racket.

 Laurent



 On Mon, Sep 16, 2013 at 5:04 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 Hi Laurent,

 I think that the solution to this are binary builds versions of
 a package that only have the bytecode and documentation.

 We're a bit behind on binary builds, because when they were discussed
 for the main repository [1] they were rejected. I hope to be able to
 still provide them for ring-0 packages through the results of DrDr
 running tests (and thus compiling) on those packages, but it's in the
 future.

 The result would be that when you installed a package in binary
 form, you would only get the deps and not the build-deps. (And
 you'd probably get those in binary form too.)

 Jay

 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html

 On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com
 wrote:
  Hi,
 
  (this is not a complain, just an inquiry)
 
  While installing Racket on a small server, I wanted to avoid installing
 gui
  and doc related libraries.
  The minimal install was great!
 
  Then I wanted to install a package of my own (the aptly named bazaar),
  which requires images and other gui libs (which I actually would not
 use
  on the server), among other things, but no doc
 
  But the images package draws racket-doc and gui-doc dependencies,
 which in
  turn draws practically all of Racket. And it then takes a much longer
 time
  for `raco setup` to do its job that I had hoped for.
 
  Certainly, this can be resolved by splitting images and bazaar into
 lib,
  gui and docs packages, but I foresee another problem:
  It's difficult to enforce such a split for third-party libraries, as it
 puts
  the burden on the user.
  And the first package like that to be installed will again draw all of
  Racket dependencies.
 
  This is probably not a trivial matter, but what can be done about this?
 
  My dream would be that gui and doc dependencies are never triggered,
 without
  preventing the packages I actually use to be downloaded, but I don't
 know
  how this could actually be ensured without a good amount of magic.
 
  Merely preventing downloads does not sound like a good option though.
 
  I bet you've already discussed this far and wide, so are there any
 plans?
 
  Laurent
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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

 The glory of God is Intelligence - DC 93



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


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


Re: [racket-dev] Installing subsets of Racket

2013-09-16 Thread Laurent
Sounds good!

I think as long as it's possible to somehow choose between byte-code and
source-code packages/distributions, there should not be too much to worry
about. My server would be very happy with byte-code packages, and my
desktop with a full source-code Racket.

Laurent


On Mon, Sep 16, 2013 at 5:04 PM, Jay McCarthy jay.mccar...@gmail.comwrote:

 Hi Laurent,

 I think that the solution to this are binary builds versions of
 a package that only have the bytecode and documentation.

 We're a bit behind on binary builds, because when they were discussed
 for the main repository [1] they were rejected. I hope to be able to
 still provide them for ring-0 packages through the results of DrDr
 running tests (and thus compiling) on those packages, but it's in the
 future.

 The result would be that when you installed a package in binary
 form, you would only get the deps and not the build-deps. (And
 you'd probably get those in binary form too.)

 Jay

 1. http://www.mail-archive.com/dev@racket-lang.org/msg08879.html

 On Mon, Sep 16, 2013 at 2:32 AM, Laurent laurent.ors...@gmail.com wrote:
  Hi,
 
  (this is not a complain, just an inquiry)
 
  While installing Racket on a small server, I wanted to avoid installing
 gui
  and doc related libraries.
  The minimal install was great!
 
  Then I wanted to install a package of my own (the aptly named bazaar),
  which requires images and other gui libs (which I actually would not
 use
  on the server), among other things, but no doc
 
  But the images package draws racket-doc and gui-doc dependencies,
 which in
  turn draws practically all of Racket. And it then takes a much longer
 time
  for `raco setup` to do its job that I had hoped for.
 
  Certainly, this can be resolved by splitting images and bazaar into
 lib,
  gui and docs packages, but I foresee another problem:
  It's difficult to enforce such a split for third-party libraries, as it
 puts
  the burden on the user.
  And the first package like that to be installed will again draw all of
  Racket dependencies.
 
  This is probably not a trivial matter, but what can be done about this?
 
  My dream would be that gui and doc dependencies are never triggered,
 without
  preventing the packages I actually use to be downloaded, but I don't know
  how this could actually be ensured without a good amount of magic.
 
  Merely preventing downloads does not sound like a good option though.
 
  I bet you've already discussed this far and wide, so are there any plans?
 
  Laurent
 
  _
Racket Developers list:
http://lists.racket-lang.org/dev
 



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

 The glory of God is Intelligence - DC 93

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