"…mais ce serait peut-être l'une des plus grandes opportunités manquées de notre époque si le logiciel libre ne libérait rien d'autre que du code…"

Archive for the ‘Gestion de version’ Category

Quelques liens sur le développement de pilotes USB sous GNU/Linux: Greg Kroah-Hartman, Daniel Drake, fprint, libusb, pylibusb, lsusb.py, LDD3

Posted by Noam sur mars 22, 2010

http://archive.netbsd.se/?ml=&a=2009-01&t=6220842 

FYI, this is a patch that will be sent out in the next round to Linus
for inclusion in 2.6.25.

If anyone has any objections about it, please let me know.

thanks,

greg k-h

--------

From: Greg Kroah-Hartman
Subject: USB: mark USB drivers as being GPL only

Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the
GPL.  This patch moves the USB apis to enforce that decision.

There are no known closed source USB drivers in the wild, so this patch
should cause no problems.

Signed-off-by: Greg Kroah-Hartman

Over two years ago, the Linux USB developers stated that they believed
there was no way to create a USB kernel driver that was not under the GPL.
This patch moves the USB apis to enforce that decision.

The USB subsystem has changed a lot over time, and it has been possible
to create userspace USB drivers using usbfs/libusb/gadgetfs that operate
as fast as the USB bus allows.  Because of this, the USB subsystem will
not be allowing closed source kernel drivers to register with it, after
this grace period is over.  If anyone needs any help in converting their
closed source drivers over to use the userspace filesystems, please
contact the linux-usb-<email removed> mailing list, and the developers
there will be glad to help you out. Greg Kroah-Hartman

linux kernel

linux drivers

usb vendor id (VID), product ID

python usb module

libusb library

fprint library depends on libusb

  • http://www.reactivated.net/ (‘My fprint efforts lead to me adopting the libusb project. I am working on libusb-1.0 which will offer new features allowing for more powerful applications’)
  • http://www.reactivated.net/fprint/wiki/Main_Page (« The fprint project aims to plug a gap in the Linux desktop: support for consumer fingerprint reader devices »)
  • http://www.reactivated.net/fprint/wiki/Libfprint

    • Written in C
    • Licensed as LGPL-2.1
    • Depends on libusb for USB communication and glib
    • Primarily developed for linux, but should be fairly portable
    • Offers a single API to application developers to access the entire range of supported devices
    • Supports imaging – downloading live fingerprint scans from the device
    • Includes image processing/matching code
    • Supports enrollment/verification – enrolling a print from a known user, and then later comparing a live scan to the enrolled print

			

			
							

				
			
Posted in 2010, Années, Drivers, Git, libusb, USB | Tagué: , , , , , , ,  |    Leave a Comment »

		


			

			
Quelques nouvelles de python: python 3.1a2 release, switching to mercurial, pycon 2009


			
Posted by Noam sur avril 5, 2009


				

					
Gestion de versions: la gestion des sources de python passe de subversion à mercurial !.


    

  • http://sayspy.blogspot.com/2009/03/why-python-is-switching-to-mercurial.html (‘Starting at PyCon 2008 thanks to Barry Warsaw and the Bazaar team I started thinking about moving Python over to a distributed version control system (DVCS). While I wanted to get offline commits for the benefit of non-core developers along with easier merging from 2.6 to 3.0 (ah, the days when there are only three branches under development), I knew that would not necessarily be enough of a reason for others to switch…Based on the results of that survey where git was clearly the most disliked tool of the core developers, having the weakest Windows support, and not being implemented in Python, I decided to eliminate git from the running and announce its elimination at the first lightning talk at PyCon.When I arrived at PyCon pretty much everyone asked me about the DVCS PEP. People wanted to know how it was going, who was going to win, and giving me support/pity for what I was going through. Guido noticed this and decided to end my misery by saying he wanted to make a decision by the end of PyCon. I said I was fine with that as one was already about to be eliminated and I knew my personal preference at that exact moment aligned with Guido’s…So Monday morning came around and I walked into the sprint. I asked Guido if he was ready to make a decision. He said yes, we both said hg, and so Guido tweeted the decision before telling python-dev that we chose Mercurial…Obviously community preference as shown at PyCon played a role. No one wants to choose a DVCS that causes the community to not want to contribute to Python. And I would never choose a VCS that would cause Guido to not want to work on Python. Some people seem surprised that something non-technical played a role, but ignoring social issues is to ignore how much open source is a social phenomenon. And we are not the first project to take social preference into consideration: I know both GNOME and Pinax chose git because their developers preferred git. And there are technical reasons. Having hg being faster than bzr by 2x to 3x does matter to some extent. No one wants to cause someone to not contribute because they didn’t want to wait for a checkout. And having personally experienced long checkout times because of a subpar connection to a specific server I know this can occur. The performance margin between hg and bzr is within reason typically and is not a flat-out deal-breaker, but it doesn’t help either. Bazaar also has its short timespan of format stability working against it. The tool has changed its format at least three times based on what the man page says (1.0, 1.6, and 1.9). Mercurial, on the other hand, has been stable since I think it went public or near that time. They take great pride in the fact they have not changed it. And that stability more aligns with python-dev’s sensibilities regarding stability. Once again the Python community stands out as being friendly and understanding about stuff like this with no one really seeming to be upset that we made the decision we did.’)
    • 

  • http://mail.python.org/pipermail/python-dev/2009-March/087931.html (‘Dear Python developers,The decision is made! I’ve selected a DVCS to use for Python. We’re switching to Mercurial (Hg). The implementation and schedule is still up in the air — I am hoping that we can switch before the summer.’)
    • 



A voir 



Pycon 2009


    

  • http://pycon.blogspot.com/2009/04/all-pycon-2009-videos-uploading.html (‘The video team has pulled the trigger and all the video from the conference is being uploaded now. At the time of this post about 14 talks are now online. By the end of the day Friday, almost everything should be available (with a few minor exceptions). The videos are also integrated into the PyCon Schedule App as well, with a minor lag time. Just look for the tiny video icon: .
    
Congratulations to the entire PyCon US 2009 volunteer video team for performing this Herculean task. In total 2.2TB of video, covering 168 hours of material, were collected, edited, transcoded, and uploaded. This is divided into 96 hours from the tutorials and 72 hours from the main conference    .’)
    • 



A voir



Python 3.1a2 release




		
	
				

				
			
Posted in 2009, bazaar, Gestion de version, Git, mercurial | Tagué: , , , ,  |    Leave a Comment »

		


			

			
Systèmes de gestion de versions: subversion, bazaar


			
Posted by Noam sur mars 22, 2009


				

					
Beauccoup de mouvements encore autour des systèmes de gestion de versions distribuées git, mercurial et bazaar:


– http://arstechnica.com/open-source/news/2009/03/sourceforge-adds-support-for-new-version-control-systems.ars (‘SourceForge has launched support for Git, Bazaar, and Mercurial, the three most popular distributed version control systems. The site has also added an impressive new hosted application feature which will allow users to run various open source project management and collaboration services—including Trac, Mantis, and phpBB—on SourceForge’s infrastructure. Although SourceForge was once the dominant collaboration service for open source software, its relevance declined sharply over the past few years as it stagnated and lost ground to emerging competitors. The trend towards distributed version control systems (DVCS) looked like it would be the final nail in the coffin, but now SourceForge is preparing to make a major comeback. The Web service has gained support for Git, Mercurial, and Bazaar, the three most popular distributed version control systems. This brings the site’s total number of supported source code management technologies to five, including its existing support for CVS and Subversion. DVCS is a major technical advancement in the area of source code management. The approach offers developers an unprecedented level of power and flexibility. The three major DVCS systems have all been used to build robust project management and code hosting services—such as GitHub, Launchpad, and BitBucket—which are rapidly displacing SourceForge. Here at Ars, our Web ninjas use GitHub extensively for managing the source code that powers our website. I personally use Launchpad for several of my own projects.’)


Passage de CVS à subversion pour la documentation Debian (il y a un an mais mieux vaut tard que jamais pour que le signale :))


– http://www.ouaza.com/wp/2008/03/03/ddp-went-svn-webml-might-follow/ (‘The topic of switching from CVS to something else regularly came forward but nobody did anything. The net result is that several documentation are now maintained outside of the debian-doc repository because their respective maintainers didn’t want to stay with CVS. After noticing that the developers-reference also switched to SVN, I decided to convert the whole debian-doc CVS repository and import it in the new “ddp” SVN repository on Alioth. This is now done. Hopefully, the Debian Documentation Project can now again become the central place for writing good documentation about Debian. New contributors can be easily added through the DDP Alioth project. Volunteers are welcome to review what’s in the SVN and move obsolete documentation aside. People who moved away are welcome back. :-)‘)


Passage de sourceforge à launchpad (https://code.launchpad.net/mailman)


– http://blog.launchpad.net/general/why-launchpad-for-mailman (‘Over the last 18 months, I’ve moved GNU Mailman development from SourceForge to Launchpad.  The reasons are varied. Mailman was one of the first projects hosted on SourceForge ages ago.  I think our project id is a pride-inducing low 103, and we were even highlighted as its Project of the Month at one point.  Of course SF itself uses Mailman to serve its own mailing lists.  While the SF guys have always been great (including providing assistance during the migration to LP), I just became increasingly roadblocked by it.


The first major motivation for moving was Bazaar. This is of course the GPL’d distributed version control system developed by Canonical and used for code hosting on Launchpad.  Having come from decades of SCCS/RCS/CVS/SVN use, distributed version control systems in general and Bazaar in particular have been an enlightenment on the order of learning Python.  I mean, who’d have thunk a version control system could be fun?


After we moved code hosting to Bazaar on LP, evaluating the other benefits of Launchpad became easier.  Truth be told, there was (and still is) some resistance in the community to moving to LP because Mailman is a GNU project but LP is not open source.  That’s being fixed. The next service to migrate was the tracker, and thanks to the excellent assistance of my colleague Graham Binns, we were able to migrate the SF issues to LP.  For years, even before I joined Canonical, I let the Mailman tracker languish because I found it so difficult to use.  The simplicity and power of Launchpad’s tracker really shines for me here, especially with its ability to link across projects and artifacts (e.g. branches linked to bugs).’)


A voir:


– http://sourceforge.net/softwaremap/trove_list.php?form_cat=646 


– http://en.wikipedia.org/wiki/Subversion_(software) (‘Subversion (SVN) is a version control system initiated in 2000 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS). Subversion is well-known in the open source community and is used on many open source projects, including Apache Software Foundation, KDE, GNOME, Free Pascal, FreeBSD, GCC, Python, Django, Ruby, Mono, SourceForge.net, ExtJS and Tigris.org. Google Code also provides Subversion hosting for their open source projects. BountySource systems use it exclusively. Codeplex offers access to both subversion as well as other types of clients. Subversion is also being adopted in the corporate world. In a 2007 report by Forrester Research, Subversion was recognized as the sole leader in the Standalone Software Configuration Management (SCM) category and a strong performer in the Software Configuration and Change Management (SCCM) category.[1] Subversion is released under the Apache License, making it free software. ‘)


– http://subversion.tigris.org/development.html (‘ The best way to get involved in Subversion development is to submit a patch to fix a bug or add a new feature.  If you don’t know what to write a patch for, have a look at the list of open issues. Subversion development discussion takes place on the mailing list dev@subversion.tigris.org. You don’t need to subscribe to the list just to submit a patch or two, but if you want to be involved with Subversion development on a regular basis, you should subscribe.  It’s high-traffic, but threading tends to be fairly disciplined, so you can ignore conversations you aren’t interested in. For real-time chat, developers use the IRC channel irc.freenode.net/svn-dev (some also hang out in the user-support channel, irc.freenode.net/svn).’)


– http://svnbook.red-bean.com/ (‘This is the online home of Version    Control with Subversion,    a free book about Subversion, a    new version control system designed to supplant CVS.  As you may    have guessed from the layout of this page, this book is published by    O’Reilly Media. This is a place to    read HTML and PDF versions of the book (although you can certainly    buy a copy if you’d like to).  We’ll do our best    to keep the site up-to-date.  As Subversion development continues, the    product will continue to grow new features, and we plan to continue    documenting those changes.’)


– http://svn.collab.net/viewvc/svn/trunk/ (sources de subversion)


    

  • – http://subversion.tigris.org/hacking.html 

      

    • http://subversion.tigris.org/hacking.html#branch-based-development (‘We prefer to have development performed on the trunk.  Changes made to trunk have the highest visibility and get the greatest amount of exercise that can be expected from unreleased code.  That said, trunk is expected at all times to be stable.  It should build.  It should work.  Those policies, combined with our preference to see large changes broken up and committed in the smallest logical chunks feasible, and applied to particularly large changes (new features, sweeping code reorganizations, etc.), makes for set of rules that are almost impossible to keep.  It is in those situations that you might consider using a custom branch dedicated to your development task. The following are some guidelines to make your branch-based development work go smoothly…

      

      Branch creation and management
      

      There’s nothing particularly complex about branch-based development.  You make a branch from the trunk (or from whatever branch best serves as both source and destination for your work), and you do your work on it.  Subversion’s merge tracking feature has greatly helped to reduce the sort of mental overhead required to work in this way, so making good use of that feature (by using Subversion 1.5 or newer clients, and by performing all merges to and from the roots of branches) is highly encouraged.’)
      

      • 

    • 

       svn co http://svn.collab.net/repos/svn/trunk  (intéressant, il y ade très nombreux scripts python)
      

      • 

    • à suivre…
      • 

    

    • 


				

				
			
Posted in 2009, bazaar, Gestion de version, subversion |    Leave a Comment »

		


			

			
Python package management: « using pip requirements » from Ian Bicking


			
Posted by Noam sur décembre 17, 2008


				

					
Un article très dense et très instructif de Ian Bicking reproduit dans son intégralité:


Source: http://blog.ianbicking.org/2008/12/16/using-pip-requirements/


================================






Following onto a set of recent posts (from James, me, then James again), Martijn Faassen wrote a description of Grok’s version management.  Our ideas are pretty close, but he’s using buildout, and I’ll describe out to do the same things with pip.


Here’s a kind of development workflow that I think works well:


    

  • A framework release is prepared.  Ideally there’s a buildbot that has been running (as Pylons has, for example), so the integration has been running for a while.
    • 

  • People make sure there are released versions of all the important components. If there are known conflicts between pieces, libraries and the framework update their install_requires in their setup.py files to make sure people don’t use conflicting pieces together.
    • 

  • Once everything has been released, there is a known set of packages that work together. Using a buildbot maybe future versions will also work together, but they won’t necessarily work together with applications built on the framework. And breakage can also occur regardless of a buildbot.
    • 

  • Also, people may have versions of libraries already installed, but just because they’ve installed something doesn’t mean they really mean to stay with an old version. While known conflicts have been noted, there’s going to be lots of unknown conflicts and future conflicts.
    • 

  • When starting development with a framework, the developer would like to start with some known-good set, which is a set that can be developed by the framework developers, or potentially by any person. For instance, if you extend a public framework with an internal framework (or even a public sub-framework like Pinax) then the known-good set will be developed by a different set of people.
    • 

  • As an application is developed, the developer will add on other libraries, or use some of their own libraries. Development will probably occur at the trunk/tip of several libraries as they are developed together.
    • 

  • A developer might upgrade the entire framework, or just upgrade one piece (for instance, to get a bug fix they are interested in, or follow a branch that has functionality they care about). The developer doesn’t necessarily have the same notion of « stable » and « released » as the core framework developers have.
    • 

  • At the time of deployment the developer wants to make sure all the pieces are deployed together as they’ve tested them, and how they know them to work. At any time, another developer may want to clone the same set of libraries.
    • 

  • After initial deployment, the developer may want to upgrade a single component, if only to test that an upgrade works, or if it resolves a bug. They may test out combinations only to throw them away, and they don’t want to bump versions of libraries in order to deploy new combinations.
    • 



This is the kind of development pattern that requirement files are meant to assist with. They can provide a known-good set of packages. Or they can provide a starting point for an active line of development. Or they can provide a historical record of how something was put together.


The easy way to start a requirement file for pip is just to put the packages you know you want to work with. For instance, we’ll call this project-start.txt:


Pylons
-e svn+http://mycompany/svn/MyApp/trunk#egg=MyApp
-e svn+http://mycompany/svn/MyLibrary/trunk#egg=MyLibrary


You can plug away for a while, and maybe you decide you want to freeze the file.  So you do:


$ pip freeze -r project-start.txt project-frozen.txt


By using -r project-start.txt you give pip freeze a template for it to start with.  From that, you’ll get project-frozen.txt that will look like:


Pylons==0.9.7
-e svn+http://mycompany/svn/MyApp/trunk@1045#egg=MyApp
-e svn+http://mycompany/svn/MyLibrary/trunk@1058#egg=MyLibrary


## The following requirements were added by pip –freeze:


Beaker==0.2.1
WebHelpers==0.9.1
nose==1.4
# Installing as editable to satisfy requirement INITools==0.2.1dev-r3488:
-e svn+http://svn.colorstudy.com/INITools/trunk@3488#egg=INITools-0.2.1dev_r3488


At that point you might decide that you don’t care about the nose version, or you might have installed something from trunk when you could have used the last release. So you go and adjust some things.


Martijn also asks: how do you have framework developers maintain one file, and then also have developers maintain their own lists for their projects?


You could start with a file like this for the framework itself. Pylons for instance could ship with something like this. To install Pylons you could then do:


$ pip -E MyProject install  -r http://pylonshq.com/0.9.7-requirements.txt


You can also download that file yourself, add some comments, rename the file and add your project to it, and use that. When you freeze the order of the packages and any comments will be preserved, so you can keep track of what changed. Also it should be ameniable to source control, and diffs would be sensible.


You could also use indirection, creating a file like this for your project:


-r http://pylonshq.com/0.9.7-requirements.txt
-e svn+http://mycompany/svn/MyApp/trunk#egg=MyApp

-e svn+http://mycompany/svn/MyLibrary/trunk#egg=MyLibrary


That is, requirements files can refer to each other. So if you want to maintain your own requirements file alongside the development of an upstream requirements file, you could do that.



				

				
			
Posted in 2008, Distribution de logiciel, Génie logiciel, Gestion de version, Intégration continue, package_management, python | Tagué: , ,  |    Leave a Comment »

		


			

			
Python package management: critiques de setuptools et louanges de pip et virtualenv


			
Posted by Noam sur décembre 16, 2008


				

					
La compréhension de la gestion des packages Python est devenue essentielle avec l’arrivée de 2 nouvelles versions de Python: python 2.6 et Python 3000 (ou Python 3k)


Voici quelques articles récents:


– http://blog.ianbicking.org/2008/12/14/a-few-corrections-to-on-packaging/ (‘James Bennett recently wrote an article on Python packaging and installation, and Setuptools. There’s a lot of issues, and writing up my thoughts could take a long time, but I thought at least I should correct some errors, specifically category errors. Figuring out where all the pieces in Setuptools (and pip and virtualenv) fit is difficult…


…




pip:


This is an alternative to easy_install.  It works somewhat differently than easy_install, but not much.  Mostly it is better than easy_install, in that it has some extra features and is easier to use. Unlike easy_install, it downloads all distributions up-front, and generates the metadata to read distribution and version requirements. It uses Setuptools to generate this metadata from a setup.py file, and uses pkg_resources to parse this metadata. It then installs packages with the setuptools monkeypatches applied.  It just happens to use an option python setup.py –single-version-externally-managed, which gets Setuptools to install packages in a more flat manner, with Distro.egg-info/ directories alongside the package. Pip installs eggs! I’ve heard the many complaints about easy_install (and I’ve had many myself), but ultimately I think pip does well by just fixing a few small issues. Pip is not a repudiation of Setuptools or the basic mechanisms that easy_install uses.






virtualenv:


This is a little hack that creates isolated Python environments.  It’s based on virtual-python.py, which is something I wrote based on some documentation notes PJE wrote for Setuptools.  Basically virtualenv just creates a bin/python interpreter that has its own value of sys.prefix, but uses the system Python and standard library. It also installs Setuptools to make it easier to bootstrap the environment (because bootstrapping Setuptools is itself a bit tedious). I’ll add pip to it too sometime. Using virtualenv you don’t have to worry about different library versions, because for any one environment you will probably only need one version of a library. On any one machine you probably need different versions, which is why installing packages system-wide is problematic for most libraries. (I’ve been meaning to write a post on why I think using system packaging for libraries is counter-productive, but that’ll wait for another time.




…I don’t think zipping libraries up is all that useful, and while it should work, it doesn’t always, and it makes code harder to inspect and understand. So since it’s not that useful, I’ve disabled it when pip installs packages. I also have had it disabled on my own system for years now, by creating a distutils.cfg file with [easy_install] zip_ok = False in it. Sadly App Engine is forcing me to use zip files again, because of its absurdly small file limits… but that’s a different topic. (There is an experimental pip zip command mostly intended for App Engine.


…Another pain point is version management with setup.py and Setuptools. Indeed it is easy to get things messed up, and it is easy to piss people off by overspecifying, and sometimes things can get in a weird state for no good reason (often because of easy_install’s rather naive leap-before-you-look installation order). Pip fixes that last point, but it also tries to suggest more constructive and less painful ways to manage other pieces.


Pip requirement files are an assertion of versions that work together.  setup.py requirements (the Setuptools requirements) should contain two things: 1: all the libraries used by the distribution (without which there’s no way it’ll work) and 2: exclusions of the versions of those libraries that are known not to work.  setup.py requirements should not be viewed as an assertion that by satisfying those requirements everything will work, just that it might work. Only the end developer, testing the system together, can figure out if it really works. Then pip gives you a way to record that working set (using pip freeze), separate from any single distribution or library….


…


Tarek Ziadé | 14-Dec-08 at 5:29 pm | Permalink


    

  1.  I am new to pip, so I hope I don’t write silly things ;)It’s a good idea to have the requirements outside the package, instead of what setuptools does. So you can share them amongst several packages.

    So basically, pip’s requirements files are what Zope calls the “Known Good Set” and what Turbogears 2 does by maintaining its own PyPI server to distribute TG2 packages : a list of versions that are known to interact well in the same environment, right ?
    

    But it’s not really different from setuptools there, except that you change the requirements in a different place if something goes wrong.
    

    So to simplify the problem, couldn’t we have juste ONE requirement file in the whole Python ?
    

    This could be the clue for os packagers : they would be able to tweak this file, while developers would be able to try out their package over different requirements files (”the debian etch python requirement file” “the debian unstable python requirement file”, etc). And for specific, isolated stuff, using virtualenv would allow developer to have their own custome requirement files….
    2. 



    

  1. 

    Ian Bicking | 14-Dec-08 at 8:02 pm | Permalink
    

    As Brett points out, apt and other package managers are inappropriate because they don’t allow multiple versions of packages to be installed, local environments, and ad hoc packages
    2. 



    

  1. 

    Gael Varoquaux | 15-Dec-08 at 12:15 am | Permalink
    

    Hey Ian,
    

    This is an excellent and unbiased summary. More or less the missing manual of the current state of packaging under Python.
    

    I need to add that I really like pip. It doesn’t change much to easy_install, but it is day and night to me. Thanks for making it available.)
    2. 



    

  • http://www.b-list.org/weblog/2008/dec/15/pip/ (‘Why I like pip. So yesterday I explained some of the reasons why I don’t like setuptools. In essence, my objections boil down to one idea: application packagingdevelopment should be orthogonal concerns. The way setuptools works, however, seems to tend, inevitably, toward coupling them to each other…But toward the end of yesterday’s article I suggested pip as an alternative to pkg_resources/easy_install toolchain, and today I’d like to explain a bit more about why I prefer pip and some of the concrete benefits it offers and application  as an alternative to the setuptools… in his response to my article yesterday Ian clarified that pip just uses the setuptools APIs to do this. Which is saying something: glossing over setuptools’ warts to the point where you don’t even realize it’s being used is a pretty big deal… pip looks before it leaps, can bail out early if it’s not going to be able to install your package and will leave behind a useful log file explaining what went wrong…The point where pip really shines, though, is in the ease of specifying and creating reproducible builds. If you’ve ever dealt with having to deploy the same code base across multiple machines, you know what a headache this can be, since a huge number of factors (operating system and version, pre-installed packages and versions, system package managers and configuration, etc., etc.) can change the results of your deployment process, sometimes in subtle and difficult-to-debug ways. With pip, this is not (so much of) a problem…I mentioned pip requirements files yesterday as an alternative to the way setuptools specifies dependencies directly in setup.py, and that’s certainly one useful application of the feature, but you can take it much further: once you know which packages (and, just as important, which versions of which packages) you need, you can write them down in a simple, plain-text file, point pip at it, and it’ll install them…The last piece of the puzzle, for me, is virtualenv; virtualenv is a tool for creating and working with isolated Python environments, and is basically the only way I work with Python these days…pip integrates quite nicely with virtualenv; normally, when working in an active virtualenv, Python packaging/installation tools (pip included) will install into that virtualenv, but pip also lets you:
    • 





    

  •  Specify a virtualenv to install into (using the -E flag), and
    • 







    

  •  Create a new virtualenv and install into it.
    • 





The second one is really the killer feature, because it means you can set up a requirements file specifying a list of packages, and get pip to create a virtualenv for you and install the packages into it…… well, there’s a heck of a lot more I could write here about pip (and about virtualenv, and about some other interesting tools), but I think this is a good start and hopefully I’ve at least got you interested enough to explore a bit on your own. And I hope I’ve managed to communicate some of the practical reasons why I’ve ditched easy_install for package installation; compared to what pip can do right now (not even considering what it might be able to do in the future), easy_install just doesn’t measure up enough to justify the headaches it can create… »)


    

  • http://tarekziade.wordpress.com/2008/12/15/python-isolated-environment-pie/ (‘Right now, when Python is loaded, it uses the site module to browse the site-packages directory to populate the path with packages it find there.  .pth files are also parsed to provide extra paths. Python 2.6 has introduced per-user site-packages directory, where you can define an extra directory, which is added in the path like the central one. But both will append new paths to the environment without any rule of exclusion or version checking…A few workarounds exist to be able to express what packages (and version) an application needs to run, or to set up an isolated environment for it:
    • 

  • setuptools provides the install_requires mechanism where you can define dependencies directly inside the package, as a new metadata. It also provides a way to install two different versions of one package and let you pick by code or when the program starts, which one you want to activate.
    • 

  • virtualenv will let you create an isolated Python environment, where you can define your own site-packages. This allows you to make sure you are not conflicting with a incompatible version of a given package.
    • 

  • zc.buildout relies on setuptools and provides an isolated environment a bit similar in some aspects to virtualenv.
    • 

  • pip provides a way to describe requirements in a file, which can be used to define bundles, which are very similar to what zc.buildout provides.
    • 



But they all aim at the same goal : define a specific execution context for a specific application, and declare dependencies with no respect to other applications or to the OS environment…This proposal describes a solution that can be added to Python to provide that feature. A new file called a  Python Isolated Environment file (PIE file) can be provided by any  application to define the list of dependencies and their versions…’)

				

				
			
Posted in 2008, Distribution de logiciel, Génie logiciel, Gestion de version, package_management, python | Tagué: , , , , , , ,  |    Leave a Comment »

		


			

			
Code source, gestionnaire de versions/code: mercurial, bazaar, git


			
Posted by Noam sur juillet 7, 2008


				

					
Quelques informations concernant la gestion des programmes source sous GNU/Debian Ubuntu.


Comment obtenir les sources d’un programme sous Debian/Ubuntu ?

=========================================


Quand on installe une distribution Debian/Ubuntu nous avons un ensemble de logiciels sous forme de fichiers (ou paquets) binaires, la liste de ces « paquets » étant donné dans le fichier /etc/apt/sources.list. Si l’on veut consulter le code source correspondant à ces  programmes, il faudra:


    

  • modifier le fichier /etc/apt/sources.list (sudo gtkedit /etc/apt/sources.list) en rajoutant pour chaque ligne commençant par « deb http://xxxx… &raquo; une ligne « deb-src http://xxx… &raquo;.
    • 

  • lancer commande « sudo apt-get update » pour mettre à jour la liste des paquets.
    • 



Si l’on veut voir à quoi ressemble les sources de l’interpréteur python on se crée un répertoire ~/src/python par exemple et un simple « apt-get source python2.5 » suffira pour télécharger les sources. A cette occasion, on aura le message suivant:


Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
NOTE : l'empaquetage de 'python2.5' est maintenu dans le système de contrôle de version 'Bzr' à:
http://bazaar.launchpad.net/~doko/python/pkg2.5
Veuillez utiliser:
bzr get http://bazaar.launchpad.net/~doko/python/pkg2.5
pour télécharger les dernières mises à jours (probablement non publiées) de ce module.


On apprend donc que ce paquet Ubuntu est géré avec un logiciel de gestion de version distribué appelé ‘bazaar’ (petit nom :’ bzr’) ce logiciel étant écrit en python (faire un apt-get source bzr pour voir le code python).


Pourquoi vouloir obtenir le code source  d’un programme ?

==================================


    

  • les logiciels libres/open source étant des logiciels de très bonne qualité, il est très intéressant de voir comment tel programme a été implémenté
    • 

  • cela permet de contrôler le contenu d’un programme (absence de spywares par exemple) et/ou de faire une revue de code (http://en.wikipedia.org/wiki/Code_review)
    • 

  • si on est très motivé, cela permet de participer au développement d’un logiciel ou si l’on n’est pas développeur de participer à sa documentation.
    • 



Les gestionnaires de versions

================


La participation à un projet open source implique l’utilisation d’un gestionnaire de versions. Depuis 2003 environ, CVS  est progressivement remplacé par subversion. Et depuis quelques moi, subversion est remplacé par des systèmes de gestion distribué tels que Mercurial (ou hg, écrit lui aussi en python), git (écrit par Linus Torwals), et bazaar.


Ainsi le langage python actuellement géré avec subversion pourrait passer sous bazaar ou mercurial:  http://www.python.org/dev/bazaar/ (« Python’s source code is maintained under the Subversion revision control system.  We are experimenting with distributed revision control systems (dvcs) because of their greatly improved workflow, accessibility and merging facilities over Subversion.  While there are several serious dvcs contenders in the open source world, this page describes the experimental Bazaar mirrors of the Python Subversion tree that we are making available to developers« )


A voir:






    

  • http://en.wikipedia.org/wiki/Bazaar_(software) (« Bazaar (formerly Bazaar-NG) is a distributed revision control system sponsored by Canonical Ltd., designed to make it easier for anyone to contribute to free and open source software projects…Bazaar is written in the Python programming language, with packages for major LinuxMac OS X and Windows. Bazaar is free software and part of the  distributions, GNU project…Bazaar has support for working with some other revision control systems.[3] This allows users to branch from another system (such as Subversion), make local changes and commit them into a Bazaar branch, and then later merge them back into the other system. Bazaar has basic support for Subversion with the bzr-svn plugin.[4] There is also beginnings of support for both Mercurial[5] and Git.[6] Currently these are not feature complete, but are complete enough to show a graphical history. »)
    • 

  • http://bazaar-vcs.org/WhoUsesBzr
    • 

  • http://wiki.list.org/display/DEV/MailmanOnLaunchpad (« The Mailman source code was originally maintained using CVS, and only a few people had write access to the code. Later, development was moved to SourceForge and then the CVS repository was converted to Subversion. This proved to be a successful transition, as Subversion provided many benefits over CVS.Now however, it’s become clear that even Subversion has its limitations, and better options exist. Specifically, we are now using the distributed (or decentralized) revision control system (dvcs) called Bazaar.  Bazaar has many beneficial features, both for the core developers and for casual, third party developers. »)
    • 


				

				
			
Posted in 2008, Développement logiciel, Génie logiciel, Gestion de version, GNU/Linux, logiciel libre, python, Revue de code, ubuntu |    Leave a Comment »

		


			

			
Les nouveaux projets python: codereview/rietveld, Paver, Sphinx


			
Posted by Noam sur Mai 12, 2008


				

					
Codereview


– http://googleappengine.blogspot.com/2008/05/open-source-app-rietveld-code-review.html (« My first project as a Google engineer was an internal web app for code review. According to Wikipedia, code review is « systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers’ skills. » Not an exciting topic, perhaps, but the internal web app, which I code-named Mondrian after one of my favorite Dutch painters, was an overnight success among Google engineers (who evidently value software quality and skills development :-). I even gave a public presentation about it: you can watch the video on YouTube.« )


– http://groups.google.com/group/codereview-discuss?hl=en (« Discussion of the code review tool « Rietveld », http://codereview.appspot.com, open source at http://code.google.com/p/rietveld/.« )


Paver


– http://www.blueskyonmars.com/projects/paver/ (« Paver is a Python-based build/distribution/deployment scripting tool along the lines of Make or Rake. What makes Paver unique is its integration with commonly used Python libraries. Common tasks that were easy before remain easy. More importantly, dealing with yourKevin Dangoor of SitePen applications specific needs and requirements is now much easier…Paver is currently alpha release software. There is one major feature (zc.buildout integration) planned for 1.0. At this point, it is unlikely that there will be significant changes to the pavement syntax, but there are no guarantees. If there are breaking changes, they will almost certainly be minor…Paver was created by . »)


– http://groups.google.com/group/comp.lang.python.announce/browse_thread/thread/1b84e15dab7f02d6?hl=en (« With Version 0.7, Paver is now a full stand-in for the traditional distutils- or setuptools-based setup.py. Need to perform some extra    work before an sdist runs? No problem:




@task

def sdist():

…move files around, etc….

call_task(« distutils.command.sdist »)




You put that in your pavement.py file and now running « paver sdist » will perform your logic and then run the distutils sdist command. Paver can even generate a setup.py so « python setup.py sdist » or  « python setup.py install » work just as they always have. And to make it easier for people who don’t yet have Paver, you can include a small zip file that enables « python setup.py install » to work off of a pavement.py file even without Paver. Paver 0.7 has a bunch of new tools to help with project documentation   (taking advantage of Georg Brandl’s Sphinx and also including Ned Batchelder’s Cog). Paver now includes much better docs, too.« )


– http://nedbatchelder.com/code/cog/ (« Cog is a code generation tool.  It lets you use pieces of Python code as generators in your source files to generate whatever code you need…Cog transforms files in a very simple way: it finds chunks of Python code embedded in them, executes the Python code, and inserts its output back into the original file. The file can contain whatever text you like around the Python code. It will usually be source code« )


Sphinx


– http://sphinx.pocoo.org/ (« Sphinx is a tool that makes it easy to create intelligent and beautiful     documentation for Python projects, written by Georg Brandl and licensed     under the BSD license.It was originally created to translate the     new Python documentation, but has now been cleaned up in the hope that     it will be useful to many other projects.  (Of course, this site is also     created from reStructuredText sources using Sphinx!) »)


A voir:


– http://en.wikipedia.org/wiki/Code_review (« Code reviews can often find and remove common vulnerabilities such as format string exploits, race conditions, memory leaks and buffer overflows, thereby improving software security. Online software repositories based on Subversion with Trac, Mercurial, GIT or others allow groups of individuals to collaboratively review code. Additionally, specific tools for collaborative code review can facilitate the code review process. »)


– http://en.wikipedia.org/wiki/Software_distribution (« A software distribution is a bundle of a specific software (or a collection of multiple, even an entire operating system), already compiled and configured. It is generally the closest thing to a turnkey form of a usually GPL or open source source code for a software. It usually takes the form of either rpm, deb, tgz, msi, exe etc. installer and is downloadable from the Internet. These are also known as a Binary distributions…The Python programming language offers a distribution utility called distutils, which requires the creation of a setup.py configuration file »)


– http://docs.python.org/dist/dist.html (« Distributing Python Modules »)


– http://mail.python.org/mailman/listinfo/doc-sig (« For discussion of both the form and content of Python documentation. The SIG should work towards setting up a Python Documentation Project effort like the Linux Documentation Project. « )


– http://fr.wikipedia.org/wiki/Documentation_logicielle (« La documentation logicielle est un texte écrit qui accompagne le logiciel informatique. Elle explique comment le logiciel fonctionne, ou comment on doit l’employer. Le terme peut avoir des significations différentes pour des personnes de différents profils.La documentation constitue une partie importante de l’ingénierie logicielle, qui est trop souvent négligée…Donald Knuth a insisté sur le fait que la documentation peut être un processus très difficile de réflexion après coup et a recommandé la programmation lettrée, qui consiste à écrire la documentation en même temps et en un même lieu que le code source et à l’extraire par des moyens automatiques. »)


– http://fr.wikipedia.org/wiki/Gestion_de_configuration (« La gestion de configuration consiste à gérer la description technique d’un système (et de ses divers composants), ainsi qu’à gérer l’ensemble des modifications apportées au cours de l’évolution du système. La gestion de configuration est utilisée pour la gestion de systèmes complexes« )


– http://en.wikipedia.org/wiki/Software_deployment (« Software deployment is all of the activities that make a software system available for use. The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined. Therefore, « deployment » should be interpreted as a general process that has to be customized according to specific requirements or characteristics. A brief description of each activity will be presented later. »)

				

				
			
Posted in Distribution de logiciel, Documentation, Génie logiciel, Gestion de projet, Gestion de version, python, Revue de code | Tagué:  |    Leave a Comment »

		


			

			
Quelques outils pour développer une application open source: Une application open source basée sur JEE 5 et JBoss Seam: Nuxeo5


			
Posted by Noam sur novembre 7, 2007


				

					
Les applications Java sont souvent employées dans des environnements assez lourds. Cette situation cependant s’améliore grâce à l’utilisation d’outils open source utilisés dans d’autres projets et également grâce à la mise en oeuvre de  serveurs d’applications Java EE 5 qui implémentent les fonctionnalités extrêmement attendues telles qu’Enterprise JavaBeans 3.0 (EJB3), Java Persistence API (JPA) et JavaServer Faces (JSF).. Voulant aussi aussi parler des logiciels libres en entreprise, on s’intéressera à Nuxeo 5 qui utilise Jboss Seam en tant que composant de son framework web.


 ECM (Enterprise Content Management) : la gestion de contenu (en anglais Enterprise Content Management, ECM) vise à gérer l’ensemble des contenus d’une entreprise. Il s’agit de prendre en compte les informations sous forme électronique, qui ne sont pas structurées, comme les documents électroniques, par opposition à celles déjà structurées dans les bases de données. À titre d’exemple, on va pouvoir gérer l’ensemble des informations d’un dossier client : courriers papier, courriels, fax, contrats, etc., dans une même infrastructure)


Nuxeo 5 est une plateforme complète de gestion de contenu d’entreprise, robuste et extensible, développée selon un modèle de logiciel libre par la société Nuxeo et une communauté de contributeurs, en utilisant des technologies Java EE open source.La plateforme Nuxeo couvre l’ensemble du spectre fonctionnel et technique de l’ECM :- Gestion documentaire (GED)- Travail collaboratif– Gestion des processus métiers (workflow documentaire)- Gestion de la conformité légale ou réglementaire


– Gestion des documents d’archives (Records Management)


– Gestion des contenus multimédias


– Gestion des connaissances (KM)


Historique de Nuxeo 5: « …La finalisation de Java Enterprise Edition 5.0 (Java EE 5) était attendue en 2007 et Nuxeo voulait être en mesure de tirer parti de nouvelles fonctionnalités extrêmement attendues telles qu’Enterprise JavaBeans 3.0 (EJB3), Java Persistence API (JPA) et JavaServer Faces (JSF). Le projet de migration vers Java EE 5 a été lancé avec pour objectif de livrer la plateforme Nuxeo 5 au 4ème trimestre 2006..


En ce qui concerne Java open source, un seul nom s’est imposé : JBoss.

« Le choix de JBoss Application Server fut évident car il se trouve au

cœur d’un package logiciel open source dont nous avions déjà testé

plusieurs modules indispensables à notre projet, »


…Nuxeo 5 utilise:


– JBoss Cache pour fournir le stockage temporaire distribué de la plateforme ECM pour les données d’accès fréquent,


– JBoss  jBPM pour fournir la gestion des processus commerciaux et les flux de travaux,


– JBoss Rules pour permettre la création de règles commerciales,


– et JBoss Seam, qui est une structure innovante de programmation de composants, pour fournir une couche Web dynamique et extensible qui unifie les fonctionnalités Java EE5 telles qu’EJB3 et JSF, ainsi que les technologies Web 2.0 telles qu’Asynchronous JavaScript et XML (Ajax).




…Enfin, en tant que fournisseur de solutions open source, Nuxeo a

apprécié le processus de développement ouvert et collaboratif de

JBoss, qui a bien accueilli la participation et la contribution des clients,

des partenaires et des particuliers. Ceci est l’antithèse du logiciel

commercial, dont le développement se fait à huis clos et qui est fourni

dans une boîte noire. Grâce à son expérience utilisateur avec JBoss

Enterprise Middleware, Nuxeo est en mesure de contribuer à la direction

du développement de JBoss. Et pour finir, cela signifie avoir droit à la

parole et être entendu.


Autres sources:


– http://www.michaelyuan.com/blog/2006/11/14/seam-without-ejb3/ (« Seam has always supported POJO components in addition to EJB3 components. You can use Seam POJOs to replace EJB3 session beans and Hibernate POJOs to replace EJB3 entity beans« )


– http://www.jboss.com/products/seam ou – http://labs.jboss.com/jbossseam/  (« JBoss Seam is a powerful new application framework for building next generation Web 2.0 applications by unifying and integrating technologies such as Asynchronous JavaScript and XML (AJAX), Java Server Faces (JSF), Enterprise Java Beans (EJB3), Java Portlets and Business Process Management (BPM). Seam has been designed from the ground up to eliminate complexity at the architecture and the API level. It enables developers to assemble complex web applications with simple annotated Plain Old Java Objects (POJOs), componentized UI widgets and very little XML.« )


– http://labs.jboss.com/jbossejb3/  (« Enterprise Java Beans (EJB) 3.0 is a deep overhaul and simplification of the EJB specification. EJB 3.0’s goals are to simplify development, facilitate test driven development, and focus more on writing plain old java objects (POJOs) rather than on complex EJB APIs. EJB 3.0 has fully embraced Java Annotations introduced in JDK 5.0 and also simplifies the API for CMP entity beans by using Hibernate as the EJB 3.0 Java Persistence engine.« )


– http://www.michaelyuan.com/blog/about/ (« Welcome to my blog site! My name is Michael Yuan. I am a technologist, author, and open source advocate based in Austin, Texas. I currently work as a Technology Evangelist at the JBoss division of Red Hat Inc. Before joining JBoss, I was an independent software consultant in the field of mobile end-to-end solutions« ) et son flux RSS (http://www.michaelyuan.com/blog/category/seam/feed/)


– http://www.redhat.com/developers/rhds/index.html (« Red Hat Developer Studio is a set of eclipse-based development tools that are pre-configured for JBoss Enterprise Middleware Platforms and Red Hat Enterprise Linux. Developers are not required to use Red Hat Developer Studio to develop on JBoss Enterprise Middleware and/or Red Hat Linux. But, many find these pre-configured tools offer significant time-savings and value, making them more productive and speeding time to deployment« )


– Learn more about Seam here, and find a list of commonly answered questions here. Or, follow this road map to get started with Seam right away! You can view a recorded Seam webinar.


–  http://blogs.nuxeo.com/sections/blogs/fermigier/2007_03_08_nuxeo-s-open-source-projects-trully-community-driven-hell-yes-they (« Fortunately, the short answer is “of course we are community-driven”. With Dion’s criteria, I can confidently self-grade us at A+ (or 20/20, for french-educated people). Here are the criteria and my comments)


– http://www.nuxeo.org/sections/documentation/  (« Learn Nuxeo EP 5.1 basics with some video demos« )


– http://www.nuxeo.org/sections/community/ (« The Nuxeo projects are open source (licensed under the LGPL) and developed with the participation of the community. We mean « participation » here as either: working as a core developer, contributor, third-party component developer (we have designed Nuxeo 5 to be very easily extensible by independent people, to create an « architecture of participation »), tests (unit tests, integration tests or functional tests) writer, Maven / Eclipse specialist, documentation writer / proofreader, etc.« )


 Here is a list of what you can do to get involved with the Nuxeo 5 development:



– http://maven.nuxeo.org/ (« This website is the Apache Maven site for the Nuxeo EP As stated on the nuxeo.org site, « Nuxeo 5 is an innovative, standards-based, open source platform for ECM applications. Its component-based and service-oriented architecture makes it easy to customize and extend, making developers more efficient and ultimately, happier ». For more general information about the project, we strongly suggest that you go to the Nuxeo.org website. What you will find on this site are highly technical, developers-focussed, information related to the project. These information are generated by the build tool we use (and we recommend to third-parties that which to use or extend the platform), Apache Maven, from the source code and meta-information developers put in the source. open source ECM platform. »)


– http://maven.nuxeo.org/source-repository.html (« This project uses Subversionhttp://svnbook.red-bean.com/ to manage its source code. Instructions on Subversion use can be found at . »)


– Accès aux sources


    

  • Anonymous access
    • 



The source can be checked out anonymously from SVN with this command:


$ svn checkout http://svn.nuxeo.org/nuxeo/nuxeo-ep/trunk nuxeo-ecm




    

  •  Developer access
    • 



 Everyone can access the Subversion repository via HTTPS, but Committers must checkout the Subversion repository via HTTPS.


$ svn checkout https://svn.nuxeo.org/nuxeo/nuxeo-ep/trunk nuxeo-ecm




– http://in.relation.to/Bloggers/Seam2IsOut (« …the most important thing about the new release is simply that the codebase is much cleaner. The migration to JSF 1.2 allowed us to solve many problems and remove quite a few hacks. We also repackaged built-in components according to a much more logical schema…« )


– http://en.wikipedia.org/wiki/Apache_Maven (« …Maven is a software tool for Java programming language project management and automated software build. It is similar in functionality to the Apache Ant tool (and to a lesser extent, PHP’s PEAR and Perl’s CPAN), but has a simpler build configuration model, based on an XML format. Maven is hosted by the Apache Software Foundation, where it was formerly part of the Jakarta Project. Maven uses a construct known as a Project Object Model (POM) to describe the software project being built, its dependencies on other external modules and components, and the build order…« )


– http://fr.wikipedia.org/wiki/JBoss (« JBoss Application Server est un serveur d’applications J2EE Libre entièrement écrit en Java, publié sous licence LGPL. Parce que le logiciel est écrit en Java, JBoss Application Server peut être utilisé sur tout système d’exploitation fournissant une machine virtuelle Java (JVM). Les développeurs du cœur de JBoss ont tous été employés par une société de services appelée « JBoss Inc. ». Celle-ci a été créée par Marc Fleury, le concepteur de la première version de JBoss. Le projet est sponsorisé par un réseau mondial de partenaires et utilise un business model fondé sur le service. En avril 2006, Red Hat a racheté JBoss Inc. En février 2007 Marc Fleury quitte le groupe Red Hat. JBoss Application Server implémente entièrement l’ensemble des services J2EE. Cela inclue JBoss Portal, JBoss Seam, Tomcat et les frameworks Hibernate, jBPM, et Rules. »)


– http://fr.wikipedia.org/wiki/Subversion_(logiciel)  (« Subversion (en abrégé svn) est un système de gestion de versions, distribué sous licence Apache et BSD. Il a été conçu pour remplacer CVS. Ses auteurs s’appuient volontairement sur les mêmes concepts (notamment sur le principe du dépôt centralisé et unique) et considèrent que le modèle de CVS est le bon, et que seule son implémentation est en cause. Le projet a été lancé en février 2000 par CollabNet, avec l’embauche par Jim Blandy de Karl Fogel, qui travaillait déjà sur un nouveau gestionnaire de version. »)


– http://en.wikipedia.org/wiki/Enterprise_JavaBean (« Enterprise Java Bean is a managed, server-side component architecture for modular construction of enterprise applications.The EJB specification is one of the several Java APIs in the Java Platform, Enterprise Edition. The EJB specification was originally developed in 1997 by  IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1) and JSR 220 (EJB 3.0). The EJB specification intends to provide a standard way to implement the back-end ‘business’ code typically found in enterprise applications (as opposed to ‘front-end’ user-interface code). Such code was frequently found to reproduce the same types of problems, and it was found that solutions to these problems are often repeatedly re-implemented by programmers. Enterprise Java Beans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.)


– http://en.wikipedia.org/wiki/Java_Persistence_API (« …The Java Persistence API was defined as part of the EJB 3.0 specification, which is itself part of the Java EE 5 platform..The Java Persistence API is designed for relational persistence, with many of the key areas taken from object-relational mapping tools such as Hibernate and TopLink. It is generally accepted that the Java Persistence API is a significant improvement on the EJB 2.0 specification…Many enterprise Java developers have been using lightweight persistent objects provided by open-source frameworks or Data Access Objects instead of entity beans because entity beans and enterprise beans were considered too heavyweight and complicated, and they could only be used in Java EE application servers. Many of the features of the third-party persistence frameworks were incorporated into the Java Persistence API, and projects like Hibernate and TopLink are now implementations of the Java Persistence API…« )


– http://en.wikipedia.org/wiki/Red_Hat (« Red Hat, Inc. (NYSE: RHT) is one of the larger and more recognized companies dedicated to open source software. It is also the largest distributor of the Linux operating system. Red Hat was founded in 1995 and has its corporate headquarters in Raleigh, North Carolina. The company is best known for its enterprise-class operating system, Red Hat Enterprise Linux and more recently through the acquisition of open source enterprise middleware vendor JBoss. Red Hat provides operating system platforms along with middleware, applications, and management solutions, as well as support, training, and consulting services. »)



				

				
			
Posted in AJAX, Architecture logicielle, Gestion de version, java, JEE, open source, Web applications, Web Frameworks, web2.0 | Tagué: , , , , , , , ,  |    Leave a Comment »

		


			

			
Outils de gestion de version (subversion,mercurial), gestion de projet (trac), intégration continue (buildbot)


			
Posted by Noam sur juillet 9, 2007


				

					
En lisant l’excellent blog de Tarek ziade (http://programmation-python.org/sections/blog) je tombe sur les sujets qui m’intéressent aujourd’hui:


1) la gestion de version  aussi bien centralisée (avec subversion de préférence à cvs) que décentralisée (mercurial ou bazaar-ng).


2) la gestion de projet  avec un outil comme trac 




3) l’intégration continue(« L’intégration continue est une technique utilisée en génie logiciel. Elle consiste à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression de l’application en cours de développement. Bien que le concept existait auparavant, l »intégration continue » se réfère généralement a la pratique de l’extreme programming« ) avec buildbot (« BuildBot is a software development continuous integration tool which automates the compile/test cycle required to validate changes to the project code base. It began as an light-weight alternative to the Mozilla project’s Tinderbox« )


En ce qui concerne subversion, trac et builbot, un excellent document d’Olivier Ramonat et Pascal Obry cité par Tarek: http://olivier.ramonat.free.fr/svn_trac_buildbot/svn_trac_buildbot_fr.html (« Ce document porte sur l’installation sur un serveur d’une suite d’outils de gestion informatique: 


    

  •  Subversion (gestion de version) pour le contrôle de version; 
    • 

  • Trac (gestion de projet) pour la  gestion de projet : Wiki, système de gestion de tickets et suivi de  l’évolution des sources (quand il est couplé à Subversion); 
    • 

  • et Buildbot (intégration continue) pour l’automatisation du packaging, des compilations  et des tests. 
    • 



 Ces trois outils peuvent interagir et permettent ensemble d’améliorer la qualité et la rapidité d’un développement logiciel. Installés sur un serveur, ils peuvent être partagés par différents projets très facilement. Il est possible de réaliser l’installation de plusieurs manières. Ce document propose un modèle d’installation et d’administration qui se veut cohérent, simple et sécurisé. »)


Webographie:


– http://en.wikipedia.org/wiki/List_of_revision_control_software


– http://trac.edgewall.org/wiki/TracMercurial (« There is an experimental plugin for Trac 0.10 and  Trac 0.11 which enables Mercurial  to be used instead of Subversion as the VersioningSystemBackend for Trac. The plugin being experimental, expect some rough edges and a somewhat unstable set of features/documentation… »)


– http://hgbook.red-bean.com/hgbook.pdf (« Distributed revision control with Mercurial…If the core functionality of Mercurial is not enough for you, it’s easy to build on. Mercurial is well suited to scripting tasks, and its clean internals and implementation in Python make it easy to add features in the form of extensions. There are a number of popular and useful extensions already available, ranging from helping to identify bugs to improving performance…Subversion is a popular revision control tool, developed to replace CVS. It has a centralised client/server architecture. Subversion and Mercurial have similarly named commands for performing the same operations, so it is easy for a

person who is familiar with one to learn to use the other. Both tools are portable to all popular operating systems« )


– http://fr.wikipedia.org/wiki/Subversion_logiciel  (« Subversion a été écrit afin de combler certains manques de CVS. Voici les principaux apports :


    

  • Les commits, ou publications des modifications sont atomiques. Un serveur Subversion utilise de façon sous-jacente une base de données capable de gérer les transactions atomiques (le plus souvent Berkeley DB) ;
    • 

  • Subversion permet le renommage et déplacement de fichiers ou de répertoires sans en perdre l’historique. ;
    • 

  • les méta-données sont versionnées : on peut attacher des propriétés, comme les permissions, à un fichier, par exemple)
    • 



– http://fr.wikipedia.org/wiki/Mercurial (« Mercurial est un logiciel de gestion de version distribué. Il est disponible sur plusieurs plate-formes : Unix-like, Windows, Mac OS X. Il est écrit principalement en Python. Mercurial a été créé pour s’utiliser via des lignes de commande. Toutes les commandes commencent par hg, en référence au symbole chimique du mercure. Ses principales caractéristiques sont entre autres :


    

  • sa rapidité et sa capacité à gérer les gros projets
    • 

  • son utilisation sans nécessiter un serveur
    • 

  • son fonctionnement complètement distribué
    • 

  • sa robustesse dans la gestion des fichiers ASCII et binaires
    • 

  • sa gestion avancée des branches et des fusions
    • 

  • son interface web intégrée »)
    • 

  • Logo mercurial
    • 



– http://fr.wikipedia.org/wiki/Gestion_de_version_d%C3%A9centralis%C3%A9e (« Quand on pense à la gestion de version, on a, en général, une vision centralisée des choses. En gros, on s’imagine un mécanisme qui va permettre à plusieurs intervenants de collecter leurs interventions. Or, en particulier avec l’arrivée des logiciels libres et leur développement communautaire, une autre façon de voir la gestion de version est apparue. Cette autre vision consiste à voir l’outil de gestion de version comme un outil permettant à chacun de travailler à son rythme, de façon désynchronisé des autres, puis d’offrir un moyen à ces développeurs de s’échanger leur travaux respectifs. C’est ce que l’on nomme la gestion de version décentralisée. »)


– http://en.wikipedia.org/wiki/Apache_Gump  (« Apache Gump is an open source Continuous Integration system, which aims to build and test all the open source Java projects, every night. Its aim is to make sure that all the projects are compatible, at both the API level and in terms of functionality matching specifications. It is hosted at gump.apache.org, and runs every night on the official Sun JVM….Gump was created by Sam Ruby, based on his experience in the Perl community. It was originally written in Java .Gump 3 is a complete rewrite in Python. It is the live version. Gump logo« )

				

				
			
Posted in Génie logiciel, Gestion de projet, Gestion de version, Intégration continue, python |    3 Comments »

		


			

			
En vrac: quelques liens sur Python: ironpython.info, bazaar, mailman, django-fr


			
Posted by Noam sur juin 4, 2007


				

					

The Mailman source code was originally maintained using CVS, and only a few people had write access to the code. Later, development was moved to SourceForge and then the CVS repository was converted to Subversion. This proved to be a successful transition, as Subversion provides many benefits over CVS.


Now however, it’s become clear that even Subversion has its limitations, and better options exist. Specifically, we want to use a distributed (or decentralized) revision control system. A dvcs has many beneficial features, both for the core developers and for casual, third party developers. These include:


    

  • No write access to the central repository is necessary in order to develop, maintain, version control, and publish unofficial contributions.
    • 

  • No connection to a repository server is necessary in order to commit changes.
    • 

  • Much better branching and merging operations; no need to commit partially completed work.
    • 

  • Much better merge tracking.
    • 

  • Ability to sign revisions with GPG.
    • 

  • Written in Python, with an easy plug-in architecture.
    • 

  • Simple and intuitive commands.
    • 





				

				
			
Posted in DotNet, Gestion de version, python |    Leave a Comment »