Newbie questions about Pliant

Newbie questions about Pliant

Module outside pliant tree

Message posted by maybe Ivan Gudym on 2001/12/13 16:17:10
I install pliant systemwide (in /usr/local/pliant), and develop 
(actually learn pliant) some program in my home directory.
When I need to add some module to my project how can I reference
it from another source file ?
If i write 'module XXX' pliant search it relative to pliant tree,
but i want search relative to current directory, or (worse) absolute
path.
Like #include <XXX> and #include "XXX" in C/C++


Thanks.
Message posted by maybe Hubert Tonneau on 2001/12/13 19:50:51
There is a lower level 'pliant_load_module' function that can do that but
it's not recommended at all.

If you want to devellop Pliant modules in your home directory, then you should
install all Pliant tree in your home directory.
If you want to save space in a multi users environment, then you can also
install it in /usr/local/pliant then remove /home/me/pliant/pliant/ directory
and set a soft link to /usr/local/pliant/pliant/
Message posted by maybe Patrice Ossona de Mendez on 2001/12/14 09:06:18
Another way to do it, under linux:
create a symbolic link in the pliant tree to a subdirectory of your
home directory:

ln -s /home/me/pliant_files /usr/local/pliant/me

then, to link with a module located at /home/me/pliant_files/mymodule.pli,
just include the line
module "/me/mymodule.pli"
Message posted by maybe Ivan Gudym on 2001/12/14 09:43:41
I don't like both methods :(
First is strange and unnatural.
Second is not secure.
In multiuser environment anybody can gain access to my private project files.
Yes, i can fix this by file attributes setting, but why should i even think
about this ? Another issue, i should ask the admin to create that soft link,
as regular user havn't write access to this directory.
I suggest to redesign this part of pliant ... not even redesign, just add
one parameter to 'module' say 'local'. It will be nice, if one can write:
module mymodule.pli local 
Message posted by maybe Hubert Tonneau on 2001/12/14 10:00:16
> First is strange and unnatural.

The natural way is to install all Pliant in your home directory (maybe with
the administrator copying only the pliant executable in a system wild directory
so that you don't have to change the path)

> module mymodule.pli local

Nothing to change in the existing code. You can write your own 'module' meta
that fits nicely alongside with the existing one. Sould be something between
10 and 20 lines of code.
Message posted by maybe Ivan Gudym on 2001/12/14 11:32:17
>> First is strange and unnatural.

> The natural way is to install all Pliant in your home directory (maybe with
> the administrator copying only the pliant executable in a system wild directory
> so that you don't have to change the path)

Hmm, pliant is general purpose language ? So it should be installed systemwide.
That's absolutly clear for me. So what about symbolic links ?
Imagine scenario: i have pliant 65 release (I really work with it now ;), then I
decide to upgrade to 67, or 121. I kill all pliant tree, install new one and ...
I must recreate all this links ?
One more scenario. I download very good word processing package, written in pliant
by one good man. I can install it in my home dir, or, ..., in pliant tree ?
So I should create symlink in one case and copy all files into pliant tree in another.
What about pliant upgrade in this case ? I can lost my package if I forget to save it.
I think word processing software include more than one module, that's right ?

>> module mymodule.pli local

> Nothing to change in the existing code. You can write your own 'module' meta
> that fits nicely alongside with the existing one. Sould be something between
> 10 and 20 lines of code.

Good answer ;), That's clear, but I suggest to change default pliant policy in 
this field. There is core pliant, there is applications, standart ones (http and so on)
and third party ones. So, why we should mix it ?


Message posted by maybe Hubert Tonneau on 2001/12/14 12:53:53
> Hmm, pliant is general purpose language ? So it should be installed systemwide.

No sofware currently succeeds to upgrade smoothly.
On most distributions, you end with several versions of the same library in
the system because not all applications will agree to work with the latest one.

With Pliant structure, you can have as many tarball of Pliant as you want
installed in a single system. You will only have to change the command line
you use to start the application in order to specify it where it must take
it's modules (and datas).
What I don't like in your scheme with absolute path is that you loose this
capability, and that's why it's not a standard feature.

> There is core pliant, there is applications, standart ones (http and so on)
> and third party ones. So, why we should mix it ?

Because (assuming that you install Pliant at root) Pliant is located in
/pliant/pliant/ not just /pliant/
it means that a third party processor from let's say wording.org should be
located at /pliant/wording/wordprocessor/

The fact to have a single tree containing everything is a feature. What I like
with Linux is the facts that drivers are part of the kernel so you don't have
problems with the driver not happy with the kernel such as with OS/2 or
Windows. What I don't like with Linux kernel is that fact that low level user
space tools (ifconfig, mount, etc) are not part of the kernel tarball so that
it prevented them to move from software RAID 0.5 to software RAID 0.9 within
the 2.2 serie (also they tend to be poor quality compared to kernel code, but
that's another story).

Pliant plans to provide a single repository for all free applications that
run nicely altogether with the latest release of Pliant core (provided the
author of the application wishes it), so that it's easy for a user to upgrade
everything at once.
For the user specific issues, there is also the plugin mechanism that
enables to make local patches that can cross releases boundaries.

I agree that Pliant release policy is unusual, but it's deaply thought.

Message posted by pom on 2001/12/14 13:49:05
> second is not secure.
If your pliant_files directory has rwx------ rights, nobody can't cross the link
but you, even to get the list of the files and subdirectories.
It lets also the ability to have some public code, some group-shared
code and some private one.

Even more simpler: have a symbolic link from /pliant/home to /home, so
that everybody can make easily modules for pliant and the access rights
will be the same as accessing through /home. This way, there is no need
to have a special procedure for new pliant users.
Message posted by maybe Ivan Gudym on 2001/12/14 14:35:56
>> Hmm, pliant is general purpose language ? So it should be installed systemwide.

> No sofware currently succeeds to upgrade smoothly.
> On most distributions, you end with several versions of the same library in
> the system because not all applications will agree to work with the latest one.
But we can try to make it easer.

> With Pliant structure, you can have as many tarball of Pliant as you want
> installed in a single system. You will only have to change the command line
> you use to start the application in order to specify it where it must take
> it's modules (and datas).
> What I don't like in your scheme with absolute path is that you loose this
> capability, and that's why it's not a standard feature.

I see, absolute path is bad, current dir even worse (pliant has not separate
compile process). I think comfortable way is to reference module relative to
current file (one that contain 'module local' command). This will be very
usefull if I, for example, move my project to another location.
Is there any problem with this scheme ?


> > There is core pliant, there is applications, standart ones (http and so on)
> > and third party ones. So, why we should mix it ?

> Because (assuming that you install Pliant at root) Pliant is located in
> /pliant/pliant/ not just /pliant/
> it means that a third party processor from let's say wording.org should be
> located at /pliant/wording/wordprocessor/
....
> Pliant plans to provide a single repository for all free applications that
> run nicely altogether with the latest release of Pliant core (provided the
> author of the application wishes it), so that it's easy for a user to upgrade
> everything at once.

OK. Imagine future, when appears many applications, written in pliant.
All of this (unlimited amount of) code will be in release. To what size will
pliant distribution grow ? As linux distributions, 2-6 CD's, more ?
Next, who will decide which software to include to release, and which not ?
How deal with software in alpha stage, not ready to release, but someone want to try
it out ? How deal with my apps, not interesting anybody outside my company ?

Is there answers to this questions ?
It seems, current scheme is very restrictive...