health-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Health-dev] GNU Health Mercurial repository at Savannah


From: Luis Falcon
Subject: Re: [Health-dev] GNU Health Mercurial repository at Savannah
Date: Tue, 13 Sep 2011 17:41:26 -0300



2011/9/13 Cédric Krier <address@hidden>
On 13/09/11 13:06 -0300, Luis Falcon wrote:
> This means that you will need to have archives for each modules like:
> >
> >    trytond_medical-1.3.1.tar.gz
> >    trytond_medical_genetics-1.3.1.tar.gz
> >    trytond_medical_gyneco-1.3.1.tar.gz
> >    ...
> >
> > But you could always have your all in one archives.
> >
>
> Remember that right now e have 12 modules. Next year, with specialties, we
> should be getting close to 20.

In Tryton we are arround 50 modules and it is not a problem.

Different functionalities.
 

> We need to make it simple to the end user. One single file to download, a
> configure script and a setup.py (but we can have also local setup for
> specific modules ). The installation process must be straight forward. Today
> it's quite simple. The idea of a "profile" works just fine.

Sorry but this is not the simple way to do in the Python world.
The simple way for the user to install is to create a Python package and
upload it to PyPI [1].

Not everything has to be Pythonic in this world ( even though I like it a lot ).

 
If we follow the Python recommendations for packaging, medical will be
packaged for al major distributions (as it is the case now with Tryton).


Please use GNU Health. Is the name. Medical was an old alias. Thanks
 
> In order to maintain scalability and development, we have to keep all this
> modules in the same Tryton version and in a single tar.gz .

I don't understand why separate package will be slower to the scalibility or
development.

> In other words,
> every release will have all the modules, and no module will have a different
> version than the others at any given release.

If so why creating modules? Put everything in 1 module if nothing can live
without the others.
 
So we have different developpers and functionality for each one. 

> We need to think that this is not like product or accounting . It's a
> Hospital Information System, and most of the modules will be needed at once.

I don't see why it is an issue.

We have over 60000 downloads and no complaints about the GNU Health modules installation .... they are extremely easy today. People follow the instructions and they have it installed in a snapshot.
 
> There is of course room for optimization in the packaging and installation
> process. For example, the installer could download the tar.gz and install
> the modules given as arguments, with their dependencies.

Why needed to download? There is package management for this purpose like
easy_install or pip. They do the job for the user and more they manage
dependencies and provide a way to update.

Having a package for each module will not prevent to have one big archive with
all the packages and a Makefile to correctly install each one.

So, that's what I said in the other mails. If we have a single .tar.gz with all the modules within it, then we can have both methods.

I'm opening a task at the Savannah with the subject of "package manager for GNU Health", so we can work on it, and assigning it to you :-)

We will come to a point of understanding.

 

[1] http://pypi.python.org/pypi

--
Cédric Krier

B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: address@hidden
Website: http://www.b2ck.com/



--
Luis Falcón
GNU Health
health.gnu.org

reply via email to

[Prev in Thread] Current Thread [Next in Thread]