Official Python API client for Discogs Reproducible: Always
Created attachment 350210 [details] discogs-client-1.1.1.ebuild
~arm is only usable if you have an arm hardware, cpu I believe, but it need be committed by a dev who need see and fix that anyhow. What is a discog and why do we need it?
Created attachment 350288 [details] discogs-client-1.1.1.ebuild Clean up the ebuild a bit
(In reply to Ian Delaney from comment #2) > ~arm is only usable if you have an arm hardware, cpu I believe, but it need > be committed by a dev who need see and fix that anyhow. > > What is a discog and why do we need it? Sorry about the arm keyword. I used the dev-python/requests ebuild and I forgot to change the KEYWORDS variable. I was trying to create an ebuild for the soon to be released media-sound/beets-1.2.0 and found that this python package was missing from portage. So I thought I should create one. The discogs plugin that is included in beets helps you identify albums and automatically add tags to your music. http://beets.readthedocs.org/en/v1.2.0/plugins/discogs.html Discogs : http://www.discogs.com/
ok I'll load it up and give it a spin tomorrow, it looks a tiny package so I think we can 'fit it in', but I'll have to go thru it and see what you may have missed.
(In reply to Ian Delaney from comment #5) > ok I'll load it up and give it a spin tomorrow, it looks a tiny package so I > think we can 'fit it in', but I'll have to go thru it and see what you may > have missed. Thanks Ian! If you want I can take it up to maintain it.
right; point 1. the tarball from pypi once again is a lemon. It lacks the test file which I place emphasis on. change your SRC_URI to SRC_URI="https://github.com/discogs/${PN/-/_}/archive/v${PV}.tar.gz -> ${P}..tar.gz" You'll then need point 2. S="${WORKDIR}"/${P/-/_} and to finish off a simple point 3. python_test() { "${PYTHON}" test_discogs_client.py || die "Tests failed under ${EPYTHON}" } Now for point 4. This is the fly in the ointment. LICENSE="BSD" I'm guessing is a carry over from the requests ebuild. From setup.py url='https://github.com/discogs/discogs-python-client', is actually wrong!!!! it's url='https://github.com/discogs/discogs_client', from https://github.com/discogs/discogs_client/blob/master/LICENSE It's not telling me it's using any license I can find that packages normally use; BSD, MIT, etc. Your task now is to establish its license or tell me it's a discog license which is new to portage. I can't add it to portage without a legitimate license. Finally, if you run the test file you should get ********************************************************************** File "README.mkd", line 187, in README.mkd Failed example: label.parent_label Expected nothing Got: <Label "Warp Records Limited"> ********************************************************************** 1 items had failures: 1 of 31 in README.mkd ***Test Failed*** 1 failures. once for each python version, so do file this upstream on confirming. Then I can add it to portage and make you a mintainer
Created attachment 350636 [details] discogs-client-1.1.1.ebuild
I changed the ebuild according to your suggestions. The license is BSD-2 (I contacted the gentoo license team) and I also run the test and it seems to be a simple fix in the test file. I will report it upstream although I doubt it will be changed soon. I wan't able to test pypy so I removed the compatibility flags for the moment. media-sound/beets (which depends on discogs-client) doesn't seem to support pypy too so I wouldn't be able to test it thoroughly.
(In reply to Theofilos Intzoglou from comment #9) > I changed the ebuild according to your suggestions. The license is BSD-2 (I > contacted the gentoo license team) good < and I also run the test and it seems to be a simple fix in the test file. Eeeer what might the fix be seeing the test file is all of 2 lines?? < I will report it upstream although I doubt > it will be changed soon. Normal, not a problem. < I won't able to test pypy so I removed the > compatibility flags for the moment. media-sound/beets (which depends on > discogs-client) doesn't seem to support pypy too so I wouldn't be able to > test it thoroughly. Seeing media-sound/beets doesn't include pypy that makes it fine for just py2.6 2.7 10 Jun 2013; Ian Delaney <idella4@gentoo.org> +discogs-client-1.1.1.ebuild, +metadata.xml: New ebuild prepared by Theofilos Intzoglou (listed as maintainer), lodged in Bug #472408, required dep to media-sound/beets-1.2.0 Next, post your 'fix' here and add the filed upstream bug to URL at top of page and we can close this fixed once that's done
Created attachment 350752 [details, diff] README.mdk.patch
> < and I also run the test and it seems to be a simple fix in the test file. > > Eeeer what might the fix be seeing the test file is all of 2 lines?? > The problem was with the README.mdk not with the test_discogs_client.py as the README.mdk doubles as a test for the library. Here is the pull request: https://github.com/discogs/discogs_client/pull/19
Theofilos, perfect, and well done. A few points: 1. The link at URL I intended to be the link to the filed bug or the pull; request. A link to pypi isn't helpful. 2. I left pypy support for /discogs-client purely because it can. Now there's a task for you. On checking the beets ebuild it still uses the old distutils. < I was trying to create an ebuild for the soon to be released media-sound/beets-1.2.0 > Prepare it using distutils-r1, approach the maintainer sochotnicky (sochotnicky@gentoo.org) for support (in fact he might need to ask us for support to convert it). What it means is that in the ebuild for the version bump of beets, the depend will be for dev-python/discogs-client[{$python_gen_usedep python{2_6,2_7})] rather than dev-python/discogs-client[${PYTHON_USEDEP}] unless the newly prepared ebuild adds pypy support. 3. See the touch up I gave to the test phase in the finished ebuild. This add wasn't essential, it simply adds a line declaring the run of the test file was effective because an effective run itself yields no output saying it did. 4. If you wish for added support or training, feel free to join us in gentoo-python irc. 12 Jun 2013; Ian Delaney <idella4@gentoo.org> +files/README.patch, discogs-client-1.1.1.ebuild: correct typo, add patch to fix tests, touch up to test phase, closes Bug #472408
Nice work Theo. I'll be gone for a few weeks so feel free to work on beets update to 1.2.0, if you base your update on 1.1.0 ebuild you should have no problems (it's already EAPI 5). As per my away message I welcome fixes/updates to my packages so continue working with python herd members and you'll be fine.