In this tread we can talk about features that could be added to next release of CEAN

It looks HTTP_PROXY only allows to specify port# (cean:pxoxyopts/0).
For those who are behind corporate firewalls/proxies it’d be nice to provide in some way proxy_user/proxy_password as well. If decided to put this directly into HTTP_PROXY URL it’s ok for me (not excluding other perhaps more appropriate forms in this case, preferably interactive)—just conform to general form of URL //<user>:@<host>:/<url-path> as defined in RFC1738.

Existing cean:proxyopts/0 has a bug. In {proxy_port,Port} `Port’ is a string(), while an integer() is expected. Fixing this and augmenting the returned list with {proxy_user,ProxyUser} and {proxy_password,ProxyPasswd} tuples I got the CEAN working from my corporate intranet. Hurrah! ;)

I have some issues to fix, and this one is in the list.
CEAN 1.2 will correct all that. more that pending fixes, here are new features on the stack:
- module dependencies will be improved
- automatic daily package upgrade
- general packages (full erlang/otp) available for download

The erl command line interface is a little raw.  How about a local gui, maybe just a yaws app?  Best to make it platform-neutral.

do you mean start script launching yaws and opening the browser on a web page with a matrix of installed server application and a start/stop button ?
that page may also include an erlang shell by the way.
actually, all packages come “as this” without any configuration.
how would you handle configurations in such a case ?
how would you define which application can be listed on that page ?

Hello Christophe,

First of all, I’ve been watching Erlang for quite a while, even bought and read the first book, but haven’t written anything to speak of in it yet, so take this for what it’s worth, probably not much.

I downloaded the base CEAN zip file on my windows machine at work, extracted it, and tried running start.bat from the command line.  No success.  Sorry, I can’t remember details as I type this from my Mac at home.  I think it either got the path to the windows erlang executable wrong, or perhaps it counted on the PATH environment variable, for which there were no instructions.  So I gave up on start.bat, found the windows executable (werl.exe?) and ran that, and tried the cean: functions.  For a long-time erlang programer, that may be enough, but if we expect newbies to get a quick start in erlang by using cean, it needs an easier user interface.

What you suggest sounds good, but it should also list available packages and allow push-button installation.  I haven’t done much GUI programming in any language, so web interfaces sound easier to me, especially since they are more easily platform-independent.  Even an interactive command-line dialog similar to the CPAN shell would help.  As for configuration, I’d strive to keep the CEAN machinery separate from the other downloaded packages.  I agree that the packages should not be altered.  Eventually, CEAN may need to publish requirements for package authors to conform to.  Perhaps a CEAN-oriented install, uninstall, and management API that each package must include in order to be available through CEAN.  Then the local CEAN interface would call into the packages to list, install, uninstall, start, stop, configure, etc.

A more comprehensive windows installer and more detailed documentation would also help.

Here’s an example of what an erlang newbie I am:  I found the function that lists all available packages, but it only displayed a handful, finishing with “...]”.  Was there some way to tell it to list the whole thing?

I’ll try CEAN on my Mac, too.

Thanks for listening.

—Phil

Concerning your windows installation problem, it’s a bug ! i’m surprised that with the high downloads of windows archive i was just never asked about before.
I do not have and do not use windows, so i can not test on that.
anyway, i will fix the glitch for the next release to come in few days.

Concerning the interface, let me think about. well this could be a great idea.

phr - 16 March 2007 04:57 PM

Here’s an example of what an erlang newbie I am:  I found the function that lists all available packages, but it only displayed a handful, finishing with “...]”.  Was there some way to tell it to list the whole thing?

if you do cean:help() you will notice a function called display. to get more info about it do
cean:help(display).

it should tell you that you want to do
cean:display(installed).
to get a complete display of the packages returned from cean:installed().

bengt

Waldemar.Rachwal - 12 March 2007 01:58 PM

It looks HTTP_PROXY only allows to specify port# (cean:pxoxyopts/0).
For those who are behind corporate firewalls/proxies it’d be nice to provide in some way proxy_user/proxy_password as well. If decided to put this directly into HTTP_PROXY URL it’s ok for me.

i would not like to add proxy_user/proxy_password to HTTP_PROXY. that is a environment variable given its value in a (perhaps world readable) file and passwords are not supposed to be stored like that. imho.

instead i would suggest cean:proxy_user/2. it takes user/password and remembers them (not in a file) for later use by install() (that is both /1 and /2).

i do not have a firewall to test with. is there someone who does?

bengt

I would not add esp. proxy_password to HTTP_PROXY when stored in a file, either. After all once env. variable was introduced, I’d provide my user/passwd while launching cean script (HTTP_PROXY=.... ./start.sh) which works well only (as many other things) under unix shell, however. (shell history files are 0600, so I’d behave “nervously” while entering the command).

But if you can do it as cean:proxy_user/2 it’s even better. Much better.

This HTTP_PROXY example shows one small thing to consider. I mean sort of configuration file. Sooner or later there will be more options describing local preferences. Something like CPAN::MyConfig module in Perl world read when cpan “shell” starts.

I’m behind a firewall so I’m willing to test it out.

Regards,
WR.

Waldemar.Rachwal - 21 March 2007 05:15 PM

This HTTP_PROXY example shows one small thing to consider. I mean sort of configuration file. Sooner or later there will be more options describing local preferences. Something like CPAN::MyConfig module in Perl world read when cpan “shell” starts.

I’m behind a firewall so I’m willing to test it out.

ok, i will try to attach the beam file. that did not work.
Error Message:  The filetype you are attempting to upload is not allowed
if you have the compiler you can have the source instead. or if i have your email i can send it directly. or send it to erlang-questions
there is an entry for proxy_user/2 in the help function.

as for configuration we have file:consult/1 as a very erlang friendly configure. once the file has been consulted i would suggest a process with loop data to keep things in memory. perhaps a cean:save_configuration(File) to save any changes, etc. with the normal hierachy of a global configure, a $HOME configure and a current directory one. as per usual.

bengt

Christophe Romain - 14 March 2007 02:29 PM

CEAN 1.2 will correct all that. more that pending fixes, here are new features on the stack:
- module dependencies will be improved
- automatic daily package upgrade

the last one sounds interesting.
do we check for the latest upgrade every time cean is started? that wold be a problem for those that never stop cean.
or do we create a process?

bengt

bengt - 21 March 2007 09:48 PM

ok, i will try to attach the beam file. that did not work.
Error Message:  The filetype you are attempting to upload is not allowed
if you have the compiler you can have the source instead. or if i have your email i can send it directly. or send it to erlang-questions
there is an entry for proxy_user/2 in the help function.
bengt

the source is always prefered. you may post it to erlang-questions or .(JavaScript must be enabled to view this email address) (although i don’t check my inbox often).
WR.

bengt - 21 March 2007 09:52 PM

do we check for the latest upgrade every time cean is started? that wold be a problem for those that never stop cean.
or do we create a process?

This will be checked at every cean:upgrade launch.
One can use a timer to launch cean:upgrade daily on systems that never stops, but I would not recommend that on a production system anyway :)

if the user gives a command we are only semiautomatic.
this is the way upgrade/0 works already. should work, anyway.

i was thinking about an automatic system, the kind you would not recommend. i see your point.