Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-30 Thread Thomas Goirand
On 01/29/2015 05:24 PM, Doug Hellmann wrote:
 
 
 On Thu, Jan 29, 2015, at 11:03 AM, Thomas Goirand wrote:
 On 01/24/2015 02:01 AM, Doug Hellmann wrote:


 On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
 Hi,

 I've just noticed that oslo.log made it to global-requirements.txt 9
 days ago. How come are we still adding some name.spaced oslo libs?
 Wasn't the outcome of the discussion in Paris that we shouldn't do that
 anymore, and that we should be using oslo-log instead of oslo.log?

 Is three something that I am missing here?

 Cheers,

 Thomas Goirand (zigo)

 The naming is described in the spec:
 http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html

 tl;dr - We did it this way to make life easier for the packagers.

 Doug

 Hi Doug,

 Sorry for the late reply.

 Well, you're not making the life of *package maintainers* more easy,
 that's in fact the opposite way, I'm afraid.

 The Debian policy is that Python module packages should be named after
 the import statement in a source file. Meaning that if we do:

 import oslo_db

 then the package should be called python-oslo-db. This means that I will
 have to rename all the Debian packages to remove the dot and put a dash
 instead. But by doing so, if OpenStack upstream is keeping the old
 naming convention, then all the requirements.txt will be wrong (by
 wrong, I mean from my perspective as a package maintainer), and the
 automated dependency calculation of dh_python2 will put package names
 with dots instead of dashes.

 So, what is going to happen, is that I'll have to, for each and every
 package, build a dictionary of translations in debian/pydist-overrides.
 
 That's unfortunate, but you're the only packager who seems to have this
 issue.
 
 I've already spent 2 months more time working on this transition than I
 planned, so I'm not planning to do anything else disruptive with it this
 cycle. If it remains a problem, or some of the other packagers support
 renaming the packages, we can discuss it at the L summit to be done
 during the L cycle.
 
 Doug

Hi Doug,

I've been thinking about this issue for a long time. And finally, I
don't think it's as bad as I previously thought.

What I could do is the opposite of what I wrote above. Which is, package
oslo.db as python-oslo.db and just add a Provides: python-oslo-db, and
that's it. Since we have oslo.db in the requirements.txt, the automated
dh_python2 dependency calculation will only add python-oslo.db in the
Depends: of the packages.

The only thing is that I have already uploaded python-oslo-context (with
a dash), and this has to be fixed, but that's only a single lib, so it
should be fine. I'll have to synchronize with guys from Canonical about
this, so we are doing the same thing on both distro.

Sorry for waiving hard for a false positive,

Cheers,

Thomas Goirand (zigo)

P.S: By the way, I'm *very* happy that you did all the work of moving
away from the namespace, Doug. Thanks a lot for that huge work!


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-29 Thread Doug Hellmann


On Thu, Jan 29, 2015, at 11:03 AM, Thomas Goirand wrote:
 On 01/24/2015 02:01 AM, Doug Hellmann wrote:
  
  
  On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
  Hi,
 
  I've just noticed that oslo.log made it to global-requirements.txt 9
  days ago. How come are we still adding some name.spaced oslo libs?
  Wasn't the outcome of the discussion in Paris that we shouldn't do that
  anymore, and that we should be using oslo-log instead of oslo.log?
 
  Is three something that I am missing here?
 
  Cheers,
 
  Thomas Goirand (zigo)
  
  The naming is described in the spec:
  http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html
  
  tl;dr - We did it this way to make life easier for the packagers.
  
  Doug
 
 Hi Doug,
 
 Sorry for the late reply.
 
 Well, you're not making the life of *package maintainers* more easy,
 that's in fact the opposite way, I'm afraid.
 
 The Debian policy is that Python module packages should be named after
 the import statement in a source file. Meaning that if we do:
 
 import oslo_db
 
 then the package should be called python-oslo-db. This means that I will
 have to rename all the Debian packages to remove the dot and put a dash
 instead. But by doing so, if OpenStack upstream is keeping the old
 naming convention, then all the requirements.txt will be wrong (by
 wrong, I mean from my perspective as a package maintainer), and the
 automated dependency calculation of dh_python2 will put package names
 with dots instead of dashes.
 
 So, what is going to happen, is that I'll have to, for each and every
 package, build a dictionary of translations in debian/pydist-overrides.

That's unfortunate, but you're the only packager who seems to have this
issue.

I've already spent 2 months more time working on this transition than I
planned, so I'm not planning to do anything else disruptive with it this
cycle. If it remains a problem, or some of the other packagers support
renaming the packages, we can discuss it at the L summit to be done
during the L cycle.

Doug

 For example:
 
 # cat debian/pydist-overrides
 oslo.db python-oslo-db
 
 This is very error prone, and I may miss lots of dependencies this way,
 leading to the packages having wrong dependencies. I have a way to avoid
 the issue, which would be to add a Provides: python-oslo.db in the
 python-oslo-db package, but this should only be considered as a
 transition thing.
 
 Also, as a side note, but it may be interesting for some: the package
 python-oslo-db should have Breaks: python-oslo.db ( OLD_VERSION) and
 Replaces: ( OLD_VERSION), as otherwise upgrades will simply fail
 (because 2 different packages can't contain the same files on the
 filesystem).
 
 So if you really want to make our lives more easy, please do the full
 migration, and move completely away from dots.
 
 Also, I'd like to tell you that I feel very sorry that I couldn't attend
 the session about the oslo namespace in Paris. I was taken by my company
 to a culture building session all the afternoon. After reading the
 above, I feel sorry that I didn't attend the namespace session instead.
 :(
 
 Cheers,
 
 Thomas Goirand (zigo)
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-29 Thread Julien Danjou
On Thu, Jan 29 2015, Thomas Goirand wrote:

Hi Thomas,

 The Debian policy is that Python module packages should be named after
 the import statement in a source file. Meaning that if we do:

 import oslo_db

 then the package should be called python-oslo-db.
 
 This means that I will have to rename all the Debian packages to
 remove the dot and put a dash instead. But by doing so, if OpenStack
 upstream is keeping the old naming convention, then all the
 requirements.txt will be wrong (by wrong, I mean from my perspective
 as a package maintainer), and the automated dependency calculation of
 dh_python2 will put package names with dots instead of dashes.

So that's a mistake from the Debian policy and/or tools.

The import statement is unrelated to the package name as it is published
on PyPI. A package could provide several Python modules, for example you
could have oslo_foo and olso_bar provided by the same package, e.g.
example oslo.foobar or oslo_foobar.

What's in requirements.txt are package names, not modules names. So if
you or Debian packages in general rely on that to build the list of
dependencies and packages name, you should somehow fix dh_python2.

What we decided to do is to name our packages (published on PyPI) by
oslo.something and provide one and only Python modules that is called
oslo_something. That is totally valid.

I understand that it's hard for you because of dh_python2 likely, but
it's Debian tooling or policy that should be fixed.

I'm not doing much Debian stuff nowadays, but I'll be happy to help you
out if you need to amend the policy or clear things out with dh_python2.

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-29 Thread Thierry Carrez
Julien Danjou wrote:
 On Thu, Jan 29 2015, Thomas Goirand wrote:
 
 Hi Thomas,
 
 The Debian policy is that Python module packages should be named after
 the import statement in a source file. Meaning that if we do:

 import oslo_db

 then the package should be called python-oslo-db.

 This means that I will have to rename all the Debian packages to
 remove the dot and put a dash instead. But by doing so, if OpenStack
 upstream is keeping the old naming convention, then all the
 requirements.txt will be wrong (by wrong, I mean from my perspective
 as a package maintainer), and the automated dependency calculation of
 dh_python2 will put package names with dots instead of dashes.
 
 So that's a mistake from the Debian policy and/or tools.
 
 The import statement is unrelated to the package name as it is published
 on PyPI. A package could provide several Python modules, for example you
 could have oslo_foo and olso_bar provided by the same package, e.g.
 example oslo.foobar or oslo_foobar.
 
 What's in requirements.txt are package names, not modules names. So if
 you or Debian packages in general rely on that to build the list of
 dependencies and packages name, you should somehow fix dh_python2.
 
 What we decided to do is to name our packages (published on PyPI) by
 oslo.something and provide one and only Python modules that is called
 oslo_something. That is totally valid.
 
 I understand that it's hard for you because of dh_python2 likely, but
 it's Debian tooling or policy that should be fixed.
 
 I'm not doing much Debian stuff nowadays, but I'll be happy to help you
 out if you need to amend the policy or clear things out with dh_python2.

The policy is actually not that strict, if I understand it correctly:


The binary package for module foo should preferably be named python-foo,
if the module name allows, but this is not required if the binary
package ships multiple modules. In the latter case the maintainer
chooses the name of the module which represents the package the most.
For subpackages such as foo.bar, the recommendation is to name the
binary packages python-foo.bar and python3-foo.bar.


That feels like a recommendation to me.

-- 
Thierry Carrez (ttx)



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-29 Thread Joshua Harlow

Just something to note; anvil has never ran had issues with this (afaik).

It seems fairly easy to have a mapping/algorithm/other... that is used 
imho (and this is just what anvil has); I don't recall that the number 
of problems with weird names has been any real issue when building 
rpms... It's sometimes an annoyance but meh, make better tooling in that 
case?


Some of the mapping + other tweaks @ 
https://github.com/stackforge/anvil/blob/master/conf/distros/redhat.yaml#L9


Also the code at:

https://github.com/stackforge/anvil/blob/master/tools/py2rpm#L161 (which 
does the brute work of most of the openstack *non-core* project package 
building). The *core* (nova, glance...) project spec files are treated 
specially @ 
https://github.com/stackforge/anvil/tree/master/conf/templates/packaging/specs 
(these are cheetah templates that are expanded; allowing for 
conditionals like '#if $newer_than_eq('2014.2')' to work...)


Food for thought,

-Josh

Thomas Goirand wrote:

On 01/24/2015 02:01 AM, Doug Hellmann wrote:


On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:

Hi,

I've just noticed that oslo.log made it to global-requirements.txt 9
days ago. How come are we still adding some name.spaced oslo libs?
Wasn't the outcome of the discussion in Paris that we shouldn't do that
anymore, and that we should be using oslo-log instead of oslo.log?

Is three something that I am missing here?

Cheers,

Thomas Goirand (zigo)

The naming is described in the spec:
http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html

tl;dr - We did it this way to make life easier for the packagers.

Doug


Hi Doug,

Sorry for the late reply.

Well, you're not making the life of *package maintainers* more easy,
that's in fact the opposite way, I'm afraid.

The Debian policy is that Python module packages should be named after
the import statement in a source file. Meaning that if we do:

import oslo_db

then the package should be called python-oslo-db. This means that I will
have to rename all the Debian packages to remove the dot and put a dash
instead. But by doing so, if OpenStack upstream is keeping the old
naming convention, then all the requirements.txt will be wrong (by
wrong, I mean from my perspective as a package maintainer), and the
automated dependency calculation of dh_python2 will put package names
with dots instead of dashes.

So, what is going to happen, is that I'll have to, for each and every
package, build a dictionary of translations in debian/pydist-overrides.
For example:

# cat debian/pydist-overrides
oslo.db python-oslo-db

This is very error prone, and I may miss lots of dependencies this way,
leading to the packages having wrong dependencies. I have a way to avoid
the issue, which would be to add a Provides: python-oslo.db in the
python-oslo-db package, but this should only be considered as a
transition thing.

Also, as a side note, but it may be interesting for some: the package
python-oslo-db should have Breaks: python-oslo.db (  OLD_VERSION) and
Replaces: (  OLD_VERSION), as otherwise upgrades will simply fail
(because 2 different packages can't contain the same files on the
filesystem).

So if you really want to make our lives more easy, please do the full
migration, and move completely away from dots.

Also, I'd like to tell you that I feel very sorry that I couldn't attend
the session about the oslo namespace in Paris. I was taken by my company
to a culture building session all the afternoon. After reading the
above, I feel sorry that I didn't attend the namespace session instead. :(

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-29 Thread Thomas Goirand
On 01/24/2015 02:01 AM, Doug Hellmann wrote:
 
 
 On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
 Hi,

 I've just noticed that oslo.log made it to global-requirements.txt 9
 days ago. How come are we still adding some name.spaced oslo libs?
 Wasn't the outcome of the discussion in Paris that we shouldn't do that
 anymore, and that we should be using oslo-log instead of oslo.log?

 Is three something that I am missing here?

 Cheers,

 Thomas Goirand (zigo)
 
 The naming is described in the spec:
 http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html
 
 tl;dr - We did it this way to make life easier for the packagers.
 
 Doug

Hi Doug,

Sorry for the late reply.

Well, you're not making the life of *package maintainers* more easy,
that's in fact the opposite way, I'm afraid.

The Debian policy is that Python module packages should be named after
the import statement in a source file. Meaning that if we do:

import oslo_db

then the package should be called python-oslo-db. This means that I will
have to rename all the Debian packages to remove the dot and put a dash
instead. But by doing so, if OpenStack upstream is keeping the old
naming convention, then all the requirements.txt will be wrong (by
wrong, I mean from my perspective as a package maintainer), and the
automated dependency calculation of dh_python2 will put package names
with dots instead of dashes.

So, what is going to happen, is that I'll have to, for each and every
package, build a dictionary of translations in debian/pydist-overrides.
For example:

# cat debian/pydist-overrides
oslo.db python-oslo-db

This is very error prone, and I may miss lots of dependencies this way,
leading to the packages having wrong dependencies. I have a way to avoid
the issue, which would be to add a Provides: python-oslo.db in the
python-oslo-db package, but this should only be considered as a
transition thing.

Also, as a side note, but it may be interesting for some: the package
python-oslo-db should have Breaks: python-oslo.db ( OLD_VERSION) and
Replaces: ( OLD_VERSION), as otherwise upgrades will simply fail
(because 2 different packages can't contain the same files on the
filesystem).

So if you really want to make our lives more easy, please do the full
migration, and move completely away from dots.

Also, I'd like to tell you that I feel very sorry that I couldn't attend
the session about the oslo namespace in Paris. I was taken by my company
to a culture building session all the afternoon. After reading the
above, I feel sorry that I didn't attend the namespace session instead. :(

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-23 Thread Louis Taylor
On Sat, Jan 24, 2015 at 01:48:32AM +0100, Thomas Goirand wrote:
 I've just noticed that oslo.log made it to global-requirements.txt 9
 days ago. How come are we still adding some name.spaced oslo libs?
 Wasn't the outcome of the discussion in Paris that we shouldn't do that
 anymore, and that we should be using oslo-log instead of oslo.log?
 
 Is three something that I am missing here?

The decision at paris was to maintain the same naming convention so the oslo
packages are consistent, since dhellman didn't want to rename a lot of packages.

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050313.html


signature.asc
Description: Digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?

2015-01-23 Thread Doug Hellmann


On Fri, Jan 23, 2015, at 07:48 PM, Thomas Goirand wrote:
 Hi,
 
 I've just noticed that oslo.log made it to global-requirements.txt 9
 days ago. How come are we still adding some name.spaced oslo libs?
 Wasn't the outcome of the discussion in Paris that we shouldn't do that
 anymore, and that we should be using oslo-log instead of oslo.log?
 
 Is three something that I am missing here?
 
 Cheers,
 
 Thomas Goirand (zigo)

The naming is described in the spec:
http://specs.openstack.org/openstack/oslo-specs/specs/kilo/drop-namespace-packages.html

tl;dr - We did it this way to make life easier for the packagers.

Doug

 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev