Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 511120

Summary: dev-python/glob2 - extended version of Python's builtin glob module
Product: Gentoo Linux Reporter: Tomáš Mózes <hydrapolic>
Component: New packagesAssignee: Default Assignee for New Packages <maintainer-wanted>
Status: RESOLVED OBSOLETE    
Severity: enhancement CC: python
Priority: Normal Keywords: EBUILD
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://github.com/miracle2k/python-glob2/
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 511116    
Attachments: glob2-0.4.1.ebuild

Description Tomáš Mózes 2014-05-23 15:25:56 UTC
Created attachment 377526 [details]
glob2-0.4.1.ebuild

Needed by beaver.
Comment 1 Ian Delaney (RETIRED) gentoo-dev 2014-05-29 08:59:59 UTC
ditto #511118. 
Is this the current beaver? euscan lists no new version out.
How can they be needed for beaver when beaver already has an established ebuild?
Comment 2 Tomáš Mózes 2014-05-29 09:51:00 UTC
We currently have app-editors/beaver in the tree, which is a text editor. This is a dependancy of another project called beaver, which is a log shipper for logstash (check 511116).

Compiles on python 3+

# diff -u glob2-0.4.1.ebuild glob2-0.4.1-r1.ebuild 
--- glob2-0.4.1.ebuild  2014-05-19 16:46:34.103309047 +0200
+++ glob2-0.4.1-r1.ebuild       2014-05-29 11:45:29.643940928 +0200
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-PYTHON_COMPAT=( python{2_6,2_7} )
+PYTHON_COMPAT=( python{2_6,2_7,3_2,3_3} )
 
 inherit distutils-r1
Comment 3 Tomáš Mózes 2014-05-29 09:59:04 UTC
Added tests and compatibility with python3+

# diff -u glob2-0.4.1.ebuild glob2-0.4.1-r1.ebuild 
--- glob2-0.4.1.ebuild  2014-05-19 16:46:34.103309047 +0200
+++ glob2-0.4.1-r1.ebuild       2014-05-29 11:57:59.786359961 +0200
@@ -4,7 +4,7 @@
 
 EAPI=5
 
-PYTHON_COMPAT=( python{2_6,2_7} )
+PYTHON_COMPAT=( python{2_6,2_7,3_2,3_3} )
 
 inherit distutils-r1
 
@@ -15,4 +15,8 @@
 LICENSE="BSD-4"
 SLOT="0"
 KEYWORDS="~amd64"
-IUSE=""
+IUSE="test"
+
+python_test() {
+       esetup.py test
+}
Comment 4 Ian Delaney (RETIRED) gentoo-dev 2014-05-31 05:41:49 UTC
ok looking good.  Now let's summarise;
1. this beaver is the one in Bug 511116 which just happens to have the same name (hate that) but there are other such duplicated names.

2. PYTHON_COMPAT=( python{2_6,2_7,3_2,3_3} ) is good but let's try for
PYTHON_COMPAT=( python{2_7,3_3,3_4} pypy ). ok pypy is pretty demanding so at a pinch we can put pypy aside for now and I can run test it if / when I get to make a copy in my local overlay and try it, which is looking pretty close.  As for py2.6, just skip it. It's up for deprecation by team python.  py3.2 is similar. It's still in but close to on the way out.  py3.4 is nice but 3.3 is enough to start with, so don't stress over 3.4 

3. Although slightly out of field here, what herd do you suggest of prefer for app-admin/beaver?  IF python I suggest you run this past the python lead. I have no real preference but the point is its his realm in part.  Technically I can just add it but this is a 'courtesy thing'.

4. Do you wish to go proxy maintainer for this or just content for us to add it?

5. To add it, I have 1 further prompt.  Can you show me a successful run of the testsuite.  The final tally + the 'OK' will be fine.  Remember I've not yet acquired or run it.  esetup.py test is quite correct but for all I know, you copied it from some other ebuild or the python docs.  There is a myriad of ways python tests are run, but that said this is likely just right.

This once over is pretty basic and normal and looks like y're doing well.

ditto this for 511118
Comment 5 Mike Gilbert gentoo-dev 2014-05-31 12:40:40 UTC
> 4. Do you wish to go proxy maintainer for this or just content for us to add it?

Just a reminder that we usually reserve proxy maintenance for orphaned packages: stuff that is already in the tree but has lost all of it's maintainers.
Comment 6 Ian Delaney (RETIRED) gentoo-dev 2014-06-01 01:50:13 UTC
right.  That was arguably getting ahead of myself somewhat. In fact sunrise had escaped me at that point and is a good / better option, except that, from experience, python packages pulling on python eclass(es) tend to leave sunrise devs umming and back pedaling.