libpytunes
libpytunes copied to clipboard
liamks
Upload to PyPi
Hi,
could you upload your library to PyPi, please? This would ease the installation (via pip) and usage.
Cheers, Philipp
Hi @phauer great idea, unfortunately I don't have the bandwidth for this at the moment. I would however accept a pull request to insure that pyItunes is in the right format for PyPi. Additionally, if you wanted to upload it I'd support that as well.
@liamks as far as I can see the code is already ready for PyPI. The only problem is that there already is pyitunes in PyPI: https://pypi.python.org/pypi/pyitunes so you'd have to change the name of the package (for example to pyitunes-lib-parser) because there can't be more than one package with the same name.
Assuming the change is made, then, you'd need to register in PyPI as maintainer, register your package name and upload the built release from your working dir -- best to follow these steps: https://packaging.python.org/distributing/#uploading-your-project-to-pypi
All those steps could be performed by someone independent, as long as you'd be OK with changing the name of the package by someone else...
I can help here, if @liamks can agree on a name. So far the suggestion is "pyitunes-lib-parser". I would like to suggest "pyitunes-lib-utils". Specifically, I wanted to add some additional capabilities using http://pandas.pydata.org.
How about "libpytunes" or "lib-pytunes" or "libtunes" or "tuneslib" or "itunes-lib" ? (I don't think it needs "py" in the name - obviously everything in pypi is python).
I'm good with changing the name. Options so far:
- pyitunes-lib-utiles
- libpytunes
- lib-pytunes
- tuneslib
- itunes-lib
- pyitunes-lib-parse
- lib-pyitunes
My preference is something that has pyitunes in it, but I will defer to you guys. Preferences?
libpytunes
Has no Google hits, so that works for me.
Whilst I am here, I would like to:
- Change name
- Implement unit tests, with a sample library
- Create an automated build
- Add more sample code
What else might we need?
Regards
Nathan
On 24 Mar 2017, at 15:16, Liam Kaufman [email protected] wrote:
I'm good with changing the name. Options so far:
• pyitunes-lib-utiles • libpytunes • lib-pytunes • tuneslib • itunes-lib • pyitunes-lib-parse • lib-pyitunes My preference is something that has pyitunes in it, but I will defer to you guys. Preferences?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
@NathanDotTo I've made you a collaborator - if you're not interested I can revoke!
I'm good with the name change and the additional effort. I'm not able to lead this, so I'd be happy if you wanted to take over.
Thanks Liam. Let’s hope I can scare up some cycles!
On 6 May 2017, at 03:13, Liam Kaufman [email protected] wrote:
@NathanDotTo I've made you a collaborator - if you're not interested I can revoke!
I'm good with the name change and the additional effort. I'm not able to lead this, so I'd be happy if you wanted to take over.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I'm doing some work on PEP-8 compliance now, which should land very soon. Please don't add to pypi until that's in, thanks.
Probably also worth bumping the version number before adding to pypi, and noting the module name change in the readme.
So with the PEP8 done and with introduction of basic tests, are we ready to do the name change and get this into pypi?
I guess. Need to create a Travis-CI build to do that. I'll look at that Monday.
On 21 May 2017, at 07:56, Scot Hacker [email protected] wrote:
So with the PEP8 done and with introduction of basic tests, are we ready to do the name change and get this into pypi?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
https://travis-ci.org/NathanDotTo/pyitunes
That is the Travis build for my fork. It seems that one needs to be the administrator of a project to be able to create a Travis build for that project.
So, I can create one for my fork, but not for the master.
I’ll create a pull request for these changes.
What new name did we decide on?
Thanks
Nathan
On 21 May 2017, at 10:18, Nathan Sowatskey [email protected] wrote:
I guess. Need to create a Travis-CI build to do that. I'll look at that Monday.
On 21 May 2017, at 07:56, Scot Hacker [email protected] wrote:
So with the PEP8 done and with introduction of basic tests, are we ready to do the name change and get this into pypi?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Seems to be libpytunes - @liamks will need to rename the repository, if everyone is still in agreement on that?
Cool.
@liamkis will also need to create a Travis CI build.
On 21 May 2017, at 20:13, Scot Hacker [email protected] wrote:
Seems to be libpytunes - @liamks will need to rename the repository, if everyone is still in agreement on that?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Right on! Nice how github does the redirect automatically. But we'd better do a search/replace on the naming right away, as setup.py still installs the egg with the old name - confusing. I'll do that now.
PR: https://github.com/liamks/libpytunes/pull/46
Current users will of course have to re-do their requirements and imports.
Out of curiosity, is Travis really a requirement for the pypi release? Doesn't seem like a blocker to me. We can always add Travis or other CI tool at any point in the future. Let's get this thing on pypi!
Not a requirement per se, but more a way to ensure that we have a “clean” release from a known baseline.
If @liamkis does not have time to do that, then we need to move on I guess.
I also like automated builds as they make it easy to check whether the code works for all versions of Python, which is hard to do manually.
On 3 Jun 2017, at 18:50, Scot Hacker [email protected] wrote:
Out of curiosity, is Travis really a requirement for the pypi release? Doesn't seem like a blocker to me. We can always add Travis or other CI tool at any point in the future. Let's get this thing on pypi!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@NathanDotTo Are one of you able to setup the .travis file? I assume from there I just have to create a travis account?
The Travis files are set up and I tested the build on my fork.
So, yes, you just need to log in to Travis.org using your Github account. You will see the repositories for which you have admin rights.
Once that works, then we can add commands to the build that do the PyPi part. We still need a branching strategy though, as we probably don't want every build of main going to PyPi.
On 3 Jun 2017, at 22:24, Liam Kaufman [email protected] wrote:
@NathanDotTo Are one of you able to setup the .travis file? I assume from there I just have to create a travis account?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
We still need a branching strategy though, as we probably don't want every build of main going to PyPi.
My recommendation would be to use git tags to record the version increments, and kick off a pypi build when a new tag is added.
I've also worked on successful oss projects that just relied on someone remembering to do a pypi push when the version changes. Not as elegant, but avoids accidental pushes and works well enough.
Thanks. Tags makes sense, the instructions are here:
https://docs.travis-ci.com/user/deployment/pypi/
So, we need to:
-
Add release instructions to the README, based on using tags as suggested.
-
Add the configuration to the .travis.yml file as described above.
We do need a PyPi account. I don’t have one, and I am not sure who should create that account. I suspect that it makes most sense for @liamks to create the account and add the encrypted password, as described in the link above, as he is the administrator.
On 5 Jun 2017, at 08:25, Scot Hacker [email protected] wrote:
We still need a branching strategy though, as we probably don't want every build of main going to PyPi.
My recommendation would be to use git tags to record the version increments, and kick off a pypi build when a new tag is added.
I've also worked on successful oss projects that just relied on someone remembering to do a pypi push when the version changes. Not as elegant, but avoids accidental pushes and works well enough.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Very good, is there a link for the build that we can see?
On 17 Jun 2017, at 04:08, Liam Kaufman [email protected] wrote:
@NathanDotTo I've logged into Travis and added libpytunes.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
OK, so there is now a pull request with the .travis.yml file and updated tests.
I thought that had been merged already ...
On 17 Jun 2017, at 16:33, Liam Kaufman [email protected] wrote:
And here's the link https://travis-ci.org/liamks/libpytunes
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
