Merge lp:~openerp-community/openerp/skitzotek_trunk_symlinks into lp:openerp

Proposed by David Bowers on 2012-02-15
Status: Needs review
Proposed branch: lp:~openerp-community/openerp/skitzotek_trunk_symlinks
Merge into: lp:openerp
Diff against target: 21 lines (+8/-3) 1 file modified
To merge this branch: bzr merge lp:~openerp-community/openerp/skitzotek_trunk_symlinks
Reviewer Review Type Date Requested Status
Olivier Dony (OpenERP) 2012-02-15 Needs Fixing on 2012-02-15
Review via email: mp+93115@code.launchpad.net

Description of the Change

[FIX] bzr_set.py
trunk has changed the path to the server addons which should be reflected in the symlinks
Symbolic links for trunk now made in server/openerp/addons

To post a comment you must log in.

Hi,

The bzr_set script is kind of deprecated for a few reasons:
- it does not setup shared bzr repositories, hence is not a good way to initialize a development environment (check out of new branches will be needlessly slow)
- for production environments it might be workable, but it fetches the extra-addons branches that are deprecated in favor of OpenERP Apps, therefore not very useful

We mention in the 6.1 release note that a new script can be used for setting up a developer environment:
   http://bit.ly/openerp61RN#heading=h.seriyncfihuy

Nevertheless, thanks for helping maintain bzr_set.py.

How about making your patch a little bit more generic and already compatible with the about-to-be-released 6.1 version? You could probably just test something like version < '6.1' to set the correct path for all future versions.
This could also be written more concisely:
  bzr_links = { 'addons/*': version < '6.1' and 'server/bin/addons' or 'server/openerp/addons/' }
(or with the Python 2.5 if/else boolean operators)

Thanks!

review: Needs Fixing
David Bowers (skitzotek) wrote :

Hi,
I'll see if I can improve the (depreciated) patch when I've learnt a bit more python, but ... this is my very first time using any of bazaar, launchpad, python, openobjects or openerp so I'm having quite a steep learning curve. I'm trying to do everything on Windows. The only documentation I've seen so far is from doc.openerp.com which didn't seem to have a link to any release notes.

Thank you for the 6.1 release notes URL, I'll have a good read.

Download full text (3.4 KiB)

Hello Olivier,

despite being "deprecated" many modules are still only maintained in the
"extra addons" branch. For instance some 5 modules required for the
Brazilian localization are to be found in that branch (because they could
also be used in other state federations, eventually USA or even Europe as a
whole), but also many useful modules like product_variant_multi,
nan_product_pack...

I insist apps.openerp.com is absolutely not a solution yet as it is. Like
if you search for magentoerpconnect you won't find the 6.1 presentation
cause it's shadowed by some old certified version, if you search
purchase_to_sale, instead of finding my module pruchase_to_sale you'll find
dozens of modules dealing with purchase OR sale....

But more importantly, today, because of OpenERP's SA idea of not using any
standard package format (like Tryton for instance), we still don't have
version dependency management (and please don't try to re-implement it
internally, I've seen all the bugs a project like Bundler had, it's not
trivial), so maintaining things is hundreds of different branches is
absolutely not viable today because you can never know what works with what
commit number, there are just too many combinations and fetching all your
branches is also tedious and error prone.

A better solution would be to have version control dependency. Else, it's
still not over at all where modules should be developed/published and given
this situation, the extra addons are still being used actively by the last
serious guys in the OpenERP ship.

I'm a bit afraid you doesn't seem aware of this problem at OpenERP SA...

Regards and thanks for all the good work nonetheless.

--
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com

On Wed, Feb 15, 2012 at 7:56 AM, Olivier Dony (OpenERP) <email address hidden>wrote:

> Review: Needs Fixing
>
> Hi,
>
> The bzr_set script is kind of deprecated for a few reasons:
> - it does not setup shared bzr repositories, hence is not a good way to
> initialize a development environment (check out of new branches will be
> needlessly slow)
> - for production environments it might be workable, but it fetches the
> extra-addons branches that are deprecated in favor of OpenERP Apps,
> therefore not very useful
>
> We mention in the 6.1 release note that a new script can be used for
> setting up a developer environment:
> http://bit.ly/openerp61RN#heading=h.seriyncfihuy
>
> Nevertheless, thanks for helping maintain bzr_set.py.
>
> How about making your patch a little bit more generic and already
> compatible with the about-to-be-released 6.1 version? You could probably
> just test something like version < '6.1' to set the correct path for all
> future versions.
> This could also be written more concisely:
> bzr_links = { 'addons/*': version < '6.1' and 'server/bin/addons' or
> 'server/openerp/addons/' }
> (or with the Python 2.5 if/else boolean operators)
>
> Thanks!
> --
>
> https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115
> Your team OpenERP Community is subscribed to branch
> lp:~openerp-community/openerp/skitzotek_trunk...

Read more...

Graeme Gellatly (gdgellatly) wrote :

to my mind extra-addons suffers a major issue which just worsens with each version. That is you never know if it has been ported to work on the current version.

What I would like to see is a community maintained extra-addons branch structure - completely seperate from openobject-addons that looks something like this.

extra-addons 5.0
   community-certified
   untested

extra-addons 6.0
   community-certified
   untested

extra-addons 6.1
   community-certified
   untested

extra-addons 6.2
   community-certified
   untested

then with each release only the community-certified addons of the previous release are ported to the untested branch of the next release. Then as they are certified (merge proposal - drivers and committers or new group community-certifiers) they are removed from untested and merged in to community-certified. This will over time remove a lot of crap that no-one uses, serve as a notice to users that they should not use untested branch, and notice to developers that while they can certainly work on the modules that it requires testing to be done, and even more so if it is in the untested of a prior release.

And then bug reports can be filed on the seperate project, managed by community for community-certified with no expectations, and a fix it yourself for untested. It will also give OpenERP a better idea of candidates for inclusion into Official certified addons.

On 02/15/2012 12:57 PM, David Bowers wrote:
> I'll see if I can improve the (depreciated) patch when I've learnt a bit
> more python, but ... this is my very first time using any of bazaar,
> launchpad, python, openobjects or openerp so I'm having quite a steep
> learning curve.

Wow, congratulations then, because you did a great job with the making and
submission of the patch! It usually takes a few tries for new contributors to
get the first merge proposal right (branch creation, target branch selection, etc.)

Do not hesitate to ask questions on the community mailing-list.

> I'm trying to do everything on Windows.

Ouch, I'm sure that quite doable, but we might be a bit lacking in terms of
tools and documentation for Windows users because most of our developers and
contributors are using the various Unix flavors. It would be great to be more
friendly to Windows users though, so do not hesitate to make suggestions.

> The only documentation I've seen so far is from doc.openerp.com which didn't
> seem to have a link to any release notes.

The documentation on doc.openerp.com is unfortunately not always up-to-date
when it comes to tools and recent developments. The procedure and guidelines
for making merge proposals are up-to-date however :-)
The 6.1 release notes have only been announced on our community channels
recently (Launchpad mailing-lists, News blog on openerp.com), so it is natural
that you might not know about them.

Welcome aboard! :-)

Simone Orsi (simone-orsi) wrote :

Hi, just a couple of things about versions and dependencies.

The ONLY way to manage versions and dependencies is to create real python packages (eggs) and publish them on pypi (http://pypi.python.org/pypi/).

This allows to pin versions and dependencies per-package and/or per-project and to manage project w/ buildout (http://www.buildout.org/) that in turn allows to replicate project environments easely and without the pain of manual picking of packages from here and there every time you deploy an istance.

For example, in the Plone world when a new version is released a buildout file w/ all the versions to be used is published (ie: http://dist.plone.org/release/4.2b2/versions.cfg) and when you want to deploy that particular version of plone you simply make your buildout extend that file (see http://plone.org/documentation/manual/developer-manual/managing-projects-with-buildout/referencemanual-all-pages).

Doing this you'll be sure that every instance you'll deploy will have the right versions. And, if you need to use a development version, or your own version, you can use buildout extensions like http://pypi.python.org/pypi/mr.developer to declare it, as Plone's core developers do into https://github.com/plone/buildout.coredev/ (see https://github.com/plone/buildout.coredev/blob/4.2/sources.cfg for example).

There are already some builouts for bootstrapping OE:

https://github.com/kalymero/OpenERP-Buildout
https://github.com/kdeldycke/openerp.buildout

but they can't use the entire power of buildout since the are no eggs for OE modules.

Moreover, by publishing eggs we'll have a track of the history and the progress of a package, and who did it, who's maintaining it. Not to mention that if you miss a package you can just "pip install" it, that's it.

I'm not working "constantly" on OpenERP anymore, but every time I come back to it for some spot work I always found myself lost in this crazy pattern of "re-implementing my own thing". I feel PITA when I have to deal w/ the big mis-use that OpenERP sa does of the python eco-system (and other systems, technologies as well). Every time they need a feature they implement their own solution (or copy&paste the entire code of a package in the core, as they formerly did with vatnumber check), no matter if there are already tools well-documented and supported by other developers and communities, and I'm scared about they'll do so for version pinning too (as Raphael already pointed out).

My $0.02

Vo Minh Thu (thu) wrote :

Hi folks,

You'll probably say we don't communicate enough our intents... anyway, better late than never ;-)

We plan to package our addons the way the Python community is accustomed to. There are two options:

- each addons has its own namespace, e.g. openerpsale, openerp_sale. When another addons want to depend on `sale`, it can import openerpsale or import openerp_sale. This is a clean option.

- a somewhat less clean option because it relies on some extra work (e.g. pkgutil) (and is probably quite debatable), is to use a shared namespace. We've decided to use that one, partly because it provides a smoother transition path (we have to be backward compatible for some time). More specificaly, we want to use the openerp.addons namespace. Addons can still be packaged separately but will be imported as, say, import openerp.addons.sale.

If you're curious, you can see e.g. the commit http://bazaar.launchpad.net/~openerp/openobject-server/trunk/revision/3969

Cheers,
Thu

Simone Orsi (simone-orsi) wrote :

> Hi folks,
>
> You'll probably say we don't communicate enough our intents... anyway, better
> late than never ;-)

That's true, but you should communicate "intents" not "things you've already done" :P

> We plan to package our addons the way the Python community is accustomed to.

That's a great news! :)

> There are two options:
>
> - each addons has its own namespace, e.g. openerpsale, openerp_sale. When
> another addons want to depend on `sale`, it can import openerpsale or import
> openerp_sale. This is a clean option.
>
> - a somewhat less clean option because it relies on some extra work (e.g.
> pkgutil) (and is probably quite debatable), is to use a shared namespace.
> We've decided to use that one, partly because it provides a smoother
> transition path (we have to be backward compatible for some time). More
> specificaly, we want to use the openerp.addons namespace. Addons can still be
> packaged separately but will be imported as, say, import openerp.addons.sale.

I'll take the Plone world as an example once again. All the core packages are in the "plone.*" namespace (the plone-only specific packages use double namespaces "plone.app.*", see https://github.com/plone). The ones from the community fall in the "collective.*" namespace (see https://github.com/collective). Of course, no one prohibit to have your own namespace such as "mycompany.*".

So, we can use "openerp.*" for core packages (like "openerp.res") and "openerpcommunity.*" for community addons.

Bests,
Simo

Numérigraphe (numerigraphe) wrote :

Please my friends be careful to have this (interesting) discussion on the mailing list instead of the merge proposal.
Lionel.

Kevin Deldycke (kevin-deldycke) wrote :

> There are already some builouts for bootstrapping OE:
>
> https://github.com/kalymero/OpenERP-Buildout
> https://github.com/kdeldycke/openerp.buildout
>
> but they can't use the entire power of buildout since the are no eggs for OE
> modules.

As the author of the https://github.com/kdeldycke/openerp.buildout I can't agree more !

OpenERP can't ignore the Python way of distributing package.

David Bowers (skitzotek) wrote :

Hi,

My Diff needs to be rejected I think.
Now I've had a look at the release notes and the new Makefile I realise that we should not be making symbolic links for 6.1+ in the server as addons also come from web and including the directories in the addons path seems to be a better solution.

However the Makefile is a pain to use under Windows and doesn't seem quite so flexible, so a .py would still be much better. To make it easier, bzr_set.py, Makefile and Makefile_helper.py should be combined into one Python script, bzr_openerp.py that is kept up to date from the server. Another script like bzr_settings.py should hold localised settings that do not get overwritten when bzr_openerp.py is auto-updated from the server. It could also list the various bugs and features that are being branched, committed and pushed.

Just an idea ...

The makefile is a temporary hack we plan to replace it by openerp-command as set of tools and helpers for openerp.
This command will provide subcommands to fetch and setup branches, scaffold modules, run tests and more...

The project is not yet ready but the branch is already public:

https://code.launchpad.net/~openerp/openerp-command/trunk

xrg (xrg) wrote :

On Thursday 16 February 2012, Graeme Gellatly wrote:
> to my mind extra-addons suffers a major issue which just worsens with each
> version. That is you never know if it has been ported to work on the
> current version.
>
> What I would like to see is a community maintained extra-addons branch
> structure - completely seperate from openobject-addons that looks
> something like this.
>
> extra-addons 5.0
> community-certified
> untested
>
> then with each release only the community-certified addons of the previous
> release are ported to the untested branch of the next release.

Moving files would be a bit messy, IMHO. It might interfere with VCS merges,
confuse translations etc.

I'd suggest to use some kind of *flag* for untested/broken modules. Just put it
inplace w/o any API change (ie. maintain 6.0 compatibility) and then update
the flag as these modules get ported or broken again.

--
Say NO to spam and viruses. Stop using Microsoft Windows!

Davide Corio @ LS (enlightx) wrote :

> Hi folks,
>
> You'll probably say we don't communicate enough our intents... anyway, better
> late than never ;-)
>
> We plan to package our addons the way the Python community is accustomed to.

Hi Thu,

is it possibile to know what this way is?

"python community" expects a set of egg, possibly on pypi.
Considering that OpenERP SA often tries to reinvent the wheel (custom continuous integration system, custom web framework, custom this and custom that when we have plenty of good apps out there) it would be nice to know your plans.
In case you are deciding for a non-standard way, we need to know that in advance so we can start to package "our own" openerp, cause we need an easy way to deploy it and we cannot wait any longer.

We are the people who customise and install openerp and who sell openerp sa services, so your decisions must be taken according to our needs. this is my personal opinion of course.

Saying <<hello people, we are doing something don't worry>> without saying what, where and why, is equal to "we don't communicate enough".

I know that this is not your fault, i guess you're not authorized to speak about internal plans but...we are losing important contributors because of how openerp behaves.

We're not asking for a community-driven project, we just need you to listen to us a bit more and keep in mind our needs when you take decisions.

Cheers

We are the people who customise and install openerp and who sell openerp sa services, so your decisions must be taken according to our needs. this is my personal opinion of course.

+1 for I have same personal opinion.

------------------ Original ------------------
From: "Davide Corio - agilebg.com"<email address hidden>;
Date: Wed, Feb 22, 2012 04:06 PM
To: "mp+93115"<email address hidden>;

Subject: Re: [Openerp-community] [Merge]lp:~openerp-community/openerp/skitzotek_trunk_symlinks intolp:openerp

> Hi folks,
>
> You'll probably say we don't communicate enough our intents... anyway, better
> late than never ;-)
>
> We plan to package our addons the way the Python community is accustomed to.

Hi Thu,

is it possibile to know what this way is?

"python community" expects a set of egg, possibly on pypi.
Considering that OpenERP SA often tries to reinvent the wheel (custom continuous integration system, custom web framework, custom this and custom that when we have plenty of good apps out there) it would be nice to know your plans.
In case you are deciding for a non-standard way, we need to know that in advance so we can start to package "our own" openerp, cause we need an easy way to deploy it and we cannot wait any longer.

We are the people who customise and install openerp and who sell openerp sa services, so your decisions must be taken according to our needs. this is my personal opinion of course.

Saying <<hello people, we are doing something don't worry>> without saying what, where and why, is equal to "we don't communicate enough".

I know that this is not your fault, i guess you're not authorized to speak about internal plans but...we are losing important contributors because of how openerp behaves.

We're not asking for a community-driven project, we just need you to listen to us a bit more and keep in mind our needs when you take decisions.

Cheers
--
https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115
Your team OpenERP Community is subscribed to branch lp:~openerp-community/openerp/skitzotek_trunk_symlinks.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : <email address hidden>
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp

Vo Minh Thu (thu) wrote :
Download full text (4.2 KiB)

About communication and expectation(, and about packaging).

It seems planning and communication with the community is a worrisome subjet. And indeed there is no surprise (at least for me, on a personal basis) this is the case!

Nobody in the R&D like to announce plan that we're not able to fulfil in due time. Still, some people (it is always hard for us to judge the community as a whole based on the comment of a few persons) are eager to know more.

Actually, it is even worse: we can't annouce things we don't plan at all. As a clear example, let's talk about the openerp-command Antony mentioned in its comment. (Similar stories can be given for a lot of things people complain they were not shared with the community before they were 'done'.)

I started that tool because I was tired of writing throw-away/one-shot scripts to try out things when working on the framework. I started that tool because when giving the one week technical training I wish I had a scaffolding script to generate some empty/sample module to show to the trainees and improve upon. I started that tool because I knew it would be a good place to add some benchmarking client-side code.

But none of the above reasons was a priority. The script was not an official, planned decision. So what? Should I have stopped working on it and wait for our management to agree with my views, wait for the PR team to do the communication, and only after resume my work?

The end result is a new, evolving script, with no clear resource (i.e. time) affected to it. And at some point, it becomes clearer in our mind we want to use that tool more widely. And we then decide to share it with the community.

I believe this is the normal course of action in open source projects/communities. You scratch your own itch, then share the result. You don't repeatedly bang on the doors of some developer to get the features you want be developed. (Or maybe I should bang on the doors of Guido to get some static typing.)

Of course, some things definitely need to be done in concert but not writing and releasing in the wild some trivial script (even if it is insanely useful).

As surely we understand it can be frustrating to feel being left on the side of the road, this is not what we're doing. Maybe it is a situation that developers are being acustomed to and not end users, but this is the reality of developement: things are not always planned, things are not always ready when we want them. Should we not release a new script or a new feature because it was not announced with a six months notice?

(About packaging.)

It is the desire of (at least part of) the R&D to be present on pypi. We still need to make sure it is the right thing. At this point, I'm sure a lot of you will think 'of course it is the right thing'. Even maybe 'this is the only right Python way to deal with packaging and dependency management'.

Well this is not as straightforward as this. For instance, is namespacing a 'Python' way? And it is not only about dependency management. OpenERP is a complex beast. People don't only create packages that depend on other packages. As a matter of fact, people create drop-in replacement for official OpenERP modul...

Read more...

Mark O (mark.o) wrote :

Hi, first time poster, long time lurker. Apologies if I'm out of line. I work for a small systems integrator who have self-started with an in-house install, and have plans to buy OPW in the near future (we want to understand it first). So while we are not necessarily "on your radar" as significant contributors, we have started submitting patches (not me personally) and we have got first-hand implementation experience. Back to the point, if I may...

> So again, what can we announce here? That we are thinking about it?
Why not? Announce an intent to look at some specific area/problem/module, and request interested parties to get in touch. Most often people can contribute their requirements, experiences with similar problems in the past or even specific use cases.
> Make some
> kind of planning? This is the kind of things that need a proof-of-concept.
Always need a proof of concept?
> And
> when you have such an executable proof-of-concept, you're very close to have
> the thing you will shortly announce (and people will complain because it was
> not planned).
Agreed, if you break cover with a proof of concept. At least if you announce your intent at the start and ask for nominations of interest, then they can't complain you didn't communicate :)
Then you can still go off and do the design, prototype the way you would have, and along the way you might just have someone who's either solved this problem before, or got themselves into some horrendous mess at some point and can share a war story that warns you of an approach to avoid. If you get no significant feedback, you develop/prototype as you would have before, and everyone is happy. If you get *loads* of input, and design/prototype something that ignores it all, you'll probably get *loads* of criticism. And rightly so I'd say. (Those pesky users, as well as being a constant PITA with their constant demands, are actually a valuable source of real-world requirements.)

>
> Here again, the best thing to do is to write code.
Only if you know you are writing code to solve the right problem, and in consideration of the greatest need. I'd argue that's what this is (or should be) about. Otherwise its coding for the art/fun/stimulation of it, not to deliver great product that meets the needs of those that use it.

Just my .02. Hope I haven't offended. My coding is such you'd probably benefit more if I stuck to testing and submitting end user requirements. We have a dev that is doing some coding, and hopefully he delivers a more tangible contribution back to something that is shaping up to be a great asset to our business. Thank you.

Unmerged revisions

38. By David Bowers on 2012-02-15

[FIX] bzr_set.py trunk Symlinks server/openerp/addons

Preview Diff

1=== modified file 'bzr_set.py'
2--- bzr_set.py 2011-03-07 10:59:15 +0000
3+++ bzr_set.py 2012-02-15 02:38:17 +0000
4@@ -64,9 +64,14 @@
5 'web': (BASEURL + '~openerp/openobject-client-web/' + webversion, True),
6 }
7
8- bzr_links = {
9- 'addons/*': 'server/bin/addons/',
10- }
11+ if version == 'trunk':
12+ bzr_links = {
13+ 'addons/*': 'server/openerp/addons/',
14+ }
15+ else:
16+ bzr_links = {
17+ 'addons/*': 'server/bin/addons/',
18+ }
19
20 if branch:
21 cmd = {'new': lambda u, l, r: run_cmd('branch', u, l, revision=r),