Yesterday, Jay McCarthy wrote:
> and you should deal with the non-proof of concept method of
> specifying it in, for instance, the info file, which is now package
> info AND collect info.
This shouldn't be a problem -- *most* of the information in the info
files that we have now is really information that applies to packages.
The only thing that I could find that doesn't is compile-omit-paths.
In fact, as I said in the past, the creation of a new info file is the
thing that is problematic.
What if, for example, there is a `name' entry in both a package info
file and in (one of) its collections? The first one would supposedly
be used when talking about the package and the second one would be
used in setup to indicate the compiled collection... Or what happens
with the `version' entry in some of the existing collections? My
guess is that the answer to both is that there shouldn't be entries
that exist in both info files (eg, the current `version' fields in the
collection info files should go away) -- and that shows that there
shouldn't be ambiguity problems.
Yesterday, Matthew Flatt wrote:
>
> Meanwhile, as we've started leaning on the package system and looked
> at how to fit our current collections into it, I think we're running
> into the same problem at another level: if "web-server-lib" and
> "web-server-doc" are both packages in a single "web-server"
> repository, and if they have to be separate directories, then we
> have yet another layer of directories that affect repository layout.
Yes, that's related, and part of my motivation to avoid that level of
splitting. I think that telling people that they should start their
hacking work with
git clone pltgit:pkg/web-server
edit web-server/web-server-lib/web-server/web-server.rkt
is making it obvious that there's some problem here...
> Maybe there's a more general answer to the directory-layout
> problem that would neatly cover single-collection packages.
I originally thought (/hoped) that you would be able to place packages
at any level. Going back to the info files -- this is what happens
now, roughly -- you just specify an info file anywhere in the tree and
it gets picked up as something very close to packages. (For example,
the game info files, or drr tools in nested directories.)
Three hours ago, Laurent wrote:
>
> Actually I use collection links instead of package links for my
> single-collection packages, which are Github clones. It kind of
> makes sense. (One more homogeneous possibility would be to add a
> `raco pkg install --link-single <my-collect/package>` command that
> is just a synonym for `raco link <my-collect/package>`.
Yes, that's what I thought should happen -- that installed packages
get linked as a single collection when they have a single collection.
> Actually I would much prefer to have `raco pkg install --link` work
> like `raco link` and have an additional `raco pkg install
> --link-multi` command instead.)
+173, with "--root" being used for both.
> - When all you need is a file, just use a file. It should have all
> the necessary information (i.e., why not have a 'info' submodule?
> E.g. to deal with dependencies)
(This would be nice, but won't work now, since there's no way to
require toplevel files. But that's fine since it corresponds to the
fact that you can't have a repository without a directory to hold it.
So I view an `in-url' thing is the way for this super-cheap code
distribution.)
--
((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
