-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload to PyPi #28
Comments
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 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:
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 ***@***.***> 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 ***@***.***> 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 ***@***.***> 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 ***@***.***> 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 ***@***.***> 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 ***@***.***> 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.
|
IT has been renamed! |
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: #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 ***@***.***> 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 ***@***.***> 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.
|
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 ***@***.***> 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.
|
@NathanDotTo I've logged into Travis and added libpytunes. |
Very good, is there a link for the build that we can see?
… On 17 Jun 2017, at 04:08, Liam Kaufman ***@***.***> 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.
|
Yes, I've just added it to the readme. |
And here's the link https://travis-ci.org/liamks/libpytunes |
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 ***@***.***> 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.
|
Merged. Next steps to getting this on pypi? |
did this ever make it to pypi? |
Bump |
Added installation steps through github repo. awaiting PR approval. |
Hi,
could you upload your library to PyPi, please? This would ease the installation (via pip) and usage.
Cheers, Philipp
The text was updated successfully, but these errors were encountered: