[Openerp-community] [Merge] lp:~openerp-community/openerp/skitzotek_trunk_symlinks into lp:openerp

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Openerp-community] [Merge] lp:~openerp-community/openerp/skitzotek_trunk_symlinks into lp:openerp

David Bowers
David Bowers has proposed merging lp:~openerp-community/openerp/skitzotek_trunk_symlinks into lp:openerp.

Requested reviews:
  OpenERP Core Team (openerp)

For more details, see:
https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115

[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
--
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.

=== modified file 'bzr_set.py'
--- bzr_set.py 2011-03-07 10:59:15 +0000
+++ bzr_set.py 2012-02-15 02:38:17 +0000
@@ -64,9 +64,14 @@
         'web': (BASEURL + '~openerp/openobject-client-web/' + webversion, True),
     }
 
-    bzr_links = {
-        'addons/*': 'server/bin/addons/',
-    }
+    if version == 'trunk':
+        bzr_links = {
+            'addons/*': 'server/openerp/addons/',
+        }
+    else:
+        bzr_links = {
+            'addons/*': 'server/bin/addons/',
+        }
 
     if branch:
         cmd = {'new': lambda u, l, r: run_cmd('branch', u, l, revision=r),


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Olivier Dony (OpenERP)
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_symlinks.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

David Bowers
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.
--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Raphael Valyi
In reply to this post by Olivier Dony (OpenERP)
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) <[hidden email]>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_symlinks.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : [hidden email]
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>

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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

[Openerp-community] Extra addons (Re: [Merge] lp:~openerp-community/openerp/skitzotek_trunk_symlinks into lp:openerp)

Numérigraphe
I agree that apps site needs to improve.

I also think the extra-addons still have a reason to exist for modules
that can be interesting to every user, but can not be accepted in the
main addons.
On the other hand, it really really needs a cleanup, because everyone
has been dumping their modules here for years and we don't know what's
general interest stuff and what's specific.
That means the community should organize to ensure quality, but we're
not there yet. Is anyone interested in managing the extras as a whole,
including merge reviews, tagging, releases and so on?

Until then I humbly think it's better to build smaller projects around
given topics (like magento integration?) and group modules that "work
together".
I also think it would be a good practice to attribute ownership of these
projects to expert teams.
For example, that's why I created a project "openerp-nomenclatures" to
group localization data modules, and made the branches belong to i18n
experts.

Lionel Sausin.

Le 15/02/2012 16:05, Raphaël Valyi - http://www.akretion.com a écrit :

> 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.
>
>


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Extra addons

Maxime Chambreuil (http://www.savoirfairelinux.com)
Hello,

Could this be a topic to discuss at the OpenERP Community Days ? I think it would be a great opportunity to move forward.

--
Maxime Chambreuil



----- Mail original -----

That means the community should organize to ensure quality, but we're
not there yet. Is anyone interested in managing the extras as a whole,
including merge reviews, tagging, releases and so on?

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

Re: [Openerp-community] Extra addons

Er. Jay Vora
Good Idea.

It needs a lot of cleanup,too.

2012/2/15 Maxime Chambreuil <[hidden email]>
Hello,

Could this be a topic to discuss at the OpenERP Community Days ? I think it would be a great opportunity to move forward.

--
Maxime Chambreuil



----- Mail original -----

That means the community should organize to ensure quality, but we're
not there yet. Is anyone interested in managing the extras as a whole,
including merge reviews, tagging, releases and so on?

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



--

Thanks,
Regards,

Er. Jay Vora
M : 91 - 9879354457.
(Not miles, just an email away...)
Twitter Facebook LinkedIn Blogger
"No Seconds to be Wasted for Formalities, I have a lot to Execute !" - Jay Vora

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Graeme Gellatly
In reply to this post by David Bowers
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.
--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Eric Caudal - www.elico-corp.com
+1.
It would add a lot of readability and make OpenERP code more accessible.

One of the major problem in OpenERP is that when you go to launchpad you never know where to pick the right revision to have a stable last revision environment. Nightly build tests and apps.openerp.com adds some features but still it is not simple for somebody who is not a top-of-the breed engineer ...

Eric CAUDAL
openerp
Eric CAUDAL, CEO
[hidden email]
Cell: + 86 186 2136 1670. Skype: elico.corp
Elico Corp - OpenERP Ready Partner, Shanghai.
http://www.openerp.net.cn

On 02/16/2012 07:58 AM, 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

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.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Alan Lord (Gmail)
In reply to this post by Graeme Gellatly
On 15/02/12 23:58, Graeme Gellatly wrote:

>
> 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.

+1 - Sounds like a great suggestion.

Al


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Stefan Rijnhart (Therp)
In reply to this post by Graeme Gellatly
On 02/16/2012 12:58 AM, 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.
>

This is not a problem of the branch. As Raphael pointed out earlier, it
is a problem with the OpenERP module format in that it does not have
version control. It hurts the extra-addons *and* the apps site.

Cheers,
Stefan.

--
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

mail: [hidden email]
tel: +31 (0) 614478606
http://therp.nl
https://twitter.com/therp_stefan


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Olivier Dony (OpenERP)
In reply to this post by David Bowers
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! :-)

--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Simone Orsi - Agile BG - Domsense
In reply to this post by David Bowers
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


--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Vo Minh Thu (OpenERP)
In reply to this post by David Bowers
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

--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Simone Orsi - Agile BG - Domsense
> 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
--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Numérigraphe
> So, we can use "openerp.*" for core packages (like "openerp.res") and "openerpcommunity.*" for community addons.
That's not so good, because the name changes when a community module
gets "adopted" by the core team (localization modules for example).
Lionel Sausin.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Numérigraphe
In reply to this post by David Bowers
Please my friends be careful to have this (interesting) discussion on the mailing list instead of the merge proposal.
Lionel.

--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Kevin Deldycke
In reply to this post by Simone Orsi - Agile BG - Domsense
> 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.
--
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     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Simone Orsi
In reply to this post by Numérigraphe
Hi all,

as suggested let's move this discussion

https://code.launchpad.net/~openerp-community/openerp/skitzotek_trunk_symlinks/+merge/93115

to the ml...


On 16/02/12 14:28, "Lionel Sausin, de la part de l'équipe informatique
Numérigraphe" wrote:
>> So, we can use "openerp.*" for core packages (like "openerp.res") and
>> "openerpcommunity.*" for community addons.
> That's not so good, because the name changes when a community module
> gets "adopted" by the core team (localization modules for example).
> Lionel Sausin.

I see no problem w/ that... When it happens you just do one simple
thing: add to the README.txt and to the pypi description the note "this
package is no longer required by openerp 7.5 (or openerp.res>2.8)" or
something like that and since you have a proper dependencies handling
you just update other packages dep according to the new name of the package.


--
Simone Orsi                 [hidden email]
Via Alliaudi, 19 - 10064  -  Pinerolo (TO)  -  Italy
Mobile: (+39) 3475004046  -   Fax: (+39) 01214469718
Domsense Srl                 http://www.domsense.com


_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
Reply | Threaded
Open this post in threaded view
|

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

Numérigraphe
Le 16/02/2012 15:22, Simone Orsi a écrit :
> (...) you just update other packages dep according to the new name of
> the package.
Won't that be a problem in itself? We have not communication channels
and no central authority, so how will I even know when a name changes?
Or do we make transitional packages a la debian to keep compatibility?
Lionel.

_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to     : [hidden email]
Unsubscribe : https://launchpad.net/~openerp-community
More help   : https://help.launchpad.net/ListHelp
12