Gems is over engineered

[Hugh Sasse]

What do you consider needed for that purpose?

[...]
documentation for those platforms which expect this. In short, we
need ruby's CONFIG hash to specify more places for things to go, [...]

Quite which combinations will make the most people happy, I cannot
say.

If you think about it, we already have a mostly determined project
directory structure dictated by a target distribution, namely FHS
--what setup.rb/install.rb need to work. So FHS is our LCD. In a way

I don't know how/if this conflicts with other platforms. I don't
use many.

that's too bad. It would be nice if we could be free of such
constraint. In fact I can't even imagine being a Windows user (knowing
next to nothing about Linux) and understanding the arrangement.

It would certainly be different under Windows. And OpenVMS I
suspect.

So if I put a data or doc file next to the .rb file it goes with in
lib/, obviously that's considered bad by FHS. In fact setup.rb won't
even install it!

Yes, it is a problem.

And there are other difficulties. I especially find it difficult to
manage a large project in that I can't organize my lib/ structure
independent of how the end-user will access the files inside. I could
have a script rearrange it before distribution, but then I can't easily
test my scripts from their development location because Ruby's require
path is too "frigid".

If we add things to CONFIG, maybe we need to add methods to
something, maybe $: or CONFIG itself, such as #find_docs(thing),
#find_lib(alibrary), #find_for_this_arch(binary). In that way (only)
the correct areas would be searched. Making path handling more like
accessing an object would seem to bring benefits of encapsulation.

That paragraph was simply brainstorming. I'm not really sure how the
ideal interface should look, but if we can make it look the same for
everyone it would help. I mean, I think you wouldn't mind where
your docs or library end up as long as you can get at them *easily* on
the target. Is that right? If the access works, it could even be a
database and not matter? Then we could make what is encapsulated
different for each group of [Debian, Windows, Solaris] users....

T.

Hugh [who was sure his sanity was here *somewhere*! ]

 

[Trans]

Interesting brainstorming Hugh.

I think it may help if we break this down to the fundamentals. Imagine
if we had no $LOAD_PATH. Imagine we had to spell everything out in
absolutes. But we don't know where exactly our files are going to end
up on the end system. How do we account for this? Well, we need a map
--a map of aliases my scripts will use to refer to it's contents (and
others can use to refer to it) that point to actual locations.

I've worked out a partial solution. I'll release it soon. But it only
does the mapping internally for the lib/ dir. To go beyond that really
means modifying Ruby to handle this more gracefully as well as adding a
tool to help generate distribution specific maps based on the alias map
provided by the developers.

In essense giving Ruby a file registry system.

T.

 

[Hugh Sasse]

Interesting brainstorming Hugh.

Thank you.

I think it may help if we break this down to the fundamentals. Imagine
if we had no $LOAD_PATH. Imagine we had to spell everything out in
absolutes. But we don't know where exactly our files are going to end
up on the end system. How do we account for this? Well, we need a map
--a map of aliases my scripts will use to refer to it's contents (and
others can use to refer to it) that point to actual locations.

Completely agree...

I've worked out a partial solution. I'll release it soon. But it only
does the mapping internally for the lib/ dir. To go beyond that really
means modifying Ruby to handle this more gracefully as well as adding a
tool to help generate distribution specific maps based on the alias map
provided by the developers.

Yes, it would have to be part of Ruby itself. Bringing it into the
whole Object hierarchy would probably allow some really fun things
to happen. For example, one of the Repackager's problems is how to
distribute the files over a heterogeneous network, with machines
having different architectures. Well, if one can get documentation
and libraries by calling some methods, they could be overridden to
get the objects (files?) from a server instead. How far could one
reduce Ruby so that only the networking-with-authentication code ran
locally, and the rest of the language was grabbed from the server?
Stdlib in a TupleSpace.....?

In essense giving Ruby a file registry system.

Yes, though I'd want to avoid the word "registry" because of how
Microsoft have given the term associations: "Do Not Touch",
"Danger[, Will Robinson]!"

T.

Thank you,
Hugh