I found a major problem in a nice pypi-package. I forked it on github and fixed the bug.
Problem: The project seems to be not maintained anymore and the author is not replying to my pull request.
I want to put the project to pypi but then some questions occurred to me:
You have to write the author and source url of the project. How do I deal with this? I'm not the author, just from the changes. I don't want to take away credit from the original guy.
The fork has old tags/version numbers. How to I start at version 1.0.0 again?
Ok, after talking to some really experienced guys, this is what they'd do:
Try reach maintainers via github
Try to find out their email address (maybe via git-commit) and ask what's going on
If they don't want to maintain it anymore, ask for maintainership
If you don't get any reply, the last and not nice solution would be that you create a new package and start on top of the versioning of the original package. Meaning the current state is at 1.10.4 and you fix a bug, your new packages first version would be 1.10.5
Related
I work on a Python web application with 20+ dependency packages. I'd love to somehow get feeds of updates for all of these packages, so that I could look at their changelogs and update quickly if the package fixes important bugs or potential security vulnerabilities. Is there a way for me to do this without hunting down the project homepage RSS feed (if one exists) for all 20 packages individually?
Ideally I'd like to be able to slurp our requirements.txt file and construct a feed automatically, but I'd settle for just manually curating a list of RSS feeds or manually subscribing some email address to a bunch of email lists.
Maybe https://requires.io/ is interesting to you?
It shows the status of all your dependencies and alerts you for security/outdated ones as well.
See here for example https://requires.io/github/edx/edx-platform/requirements/?branch=master
Github seems to have launched this feature (for other languages too!) since I posted this. See here.
If the Python packages is on PyPI, you can use libraries.io to select packages you want release emails for. This answer to a related question has additional details.
Say someone owns a repository with only one master hosting code that is compatible with Python 2.7.X. I would like to contribute to that repository with my own changes to a new branch new_branch to offer a variant of the repository that is compatible with Python 3.
I followed the steps here:
I forked the repository on GitHub on my account
I cloned my fork on my local machine
I created a new branch new_branch locally
I made the relevant changes
I committed and pushed the changes to my own fork on GitHub
I went on the browser to the GitHub page of the official repository, and asked for a pull request
The above worked, but it did a pull request from "my_account:new_branch" to "official_account:master". This is not what I want, since Python 2.7.x and Python 3 are incompatible with each other. What I would like to do is create a PR to a new branch on the official repository (e.g. with the same name "new_branch"). How can I do that? Is this possible at all?
You really don't want to do things this way. But first I'll explain how to do it, then I'll come back to explain why not to.
Using Pull Requests at GitHub has a pretty good overview, in particular the section "Changing the branch range and destination repository." It's easiest if you use a topic branch, and have the upstream owner create a topic branch of the same name; then you just pull down the menu where it says "base: master" and the choice will be right there, and he can just click the "merge" button and have no surprises.
So, why don't you want to do things this way?
First, it doesn't fit the GitHub model. Topic branches that live forever in parallel with the master branch and have multiple forks make things harder to maintain and visualize.
Second, you need both a git URL and an https URL for you code. You need people to be able to share links, pip install from top of tree, just clone the repo instead of cloning and then checking out a different branch, etc. This all means your code has to be on the master branch.
Third, if you want people to be able to install your 3.x version off PyPI, find docs at readthedocs, etc., you need a single project with a single source tree. Most such sites have a single latest version, not a latest version for each Python version, and definitely not multiple variations of the same version. (You could install completely fork the project, and create a separate foo3 project. But it's much easier for people to be able to pip install foo than to have them try that, fail, come to SO and ask why it doesn't work, and get told they probably have Python 3 and need to pip install foo3 instead.)
How do you merge two versions into a single package? The porting docs should have the most up-to-date advice, but briefly: If it's at all possible to create a single codebase that runs on both versions, that's ideal; if not, and if you can't make things work by running 2to3 or 3to2 at install time, create a parallel directory for the 3.x code (e.g., a foo3 alongside foo) and pick the appropriate directory at install time. (You can always start with that and gradually work toward a unified codebase.)
I have a number of python packages in GitHub repositories and it would be really great to have these available in PyPi. I know I could do these releases manually (update the version number, perhaps update a changelog, tag the release in GitHub, get the download url from GitHub, update PyPi with the release etc.) but I keep thinking that there must be a script/utility somewhere to make this a single-command process.
I am not massively familiar with the python packaging process, so perhaps I am coming at this from the wrong angle. I just don't think I can be the first one to have the idea of making this whole process a lot easier.
Edit: As there seems to be some confusion about what I am asking for: Are there any tools that make releasing Python packages to PyPi a faster and more streamlined process?
I have tried searching around but have yet to find anything.
Ok, I really don't know if anyone else has had this problem/concern, but I had an itch I needed to scratch so I have made this:
http://seed.readthedocs.org
I wouldn't be surprised if there is something out there already that does this better, but for now this is what I'll use :)
There is changes, software that makes the pypi publish just a single step. Looks like that is quite similar to seed.
Anyway, it would be nice if pypi could just check if on github there is a new tagged release and release it on pypi.
I'm developing coding a test django site, which I keep in a bitbucket repository in order to be able to deploy it easily on a remote server, and possible share development with a friend. I use hg for version control.
The site depends on a 3rd party app (django-registration), which I needed to customize for my site, so I forked the original app and created a 2nd repository for it (the idea being that this way I can keep up with updates on the original, which wouldnt be possible if I just pasted the code into my main site, plus add to my own custom code) (You can see some more details on this question)
My question is, how do I specify requirements on my setup.py file so that when I install my django site I get the latest version of my fork for the 3rd party app (I use distribute rather than setuptools in case that makes a difference)?
I have tried this:
install_requires = ['django', 'django-registration'],
dependency_links = ['https://myuser#bitbucket.org/myuser/django-registration#egg=django_registration']
but this gets me the latest named version on the original trunk (so not even the tip version)
Using a pip requirements file however works well:
hg+https://myuser#bitbucket.org/myuser/django-registration#egg=django-registration
gets me the latest version from my fork.
Is there a way to get this same behaviour directly from the setup.py file, without having to install first the code for the site, then running pip install -r requirements.txt?
This question is very informative, but seems to suggest I should depend on version 'dev' or the 3rd party package, which doesn't work (I guess there would have to be a specific version tagged as dev for that)
Also I'm a complete newbie in packaging / distribute / setuptools, so dont hold back spelling out the steps :)
Maybe I should change the setup.py file on my fork of the 3rd party app, and make sure it mentions a version number. Generally I'm curious to know what's a source distribution, as opposed to simply having my code on a public repository, and what would be a binary distribution in my case (an egg file?), and whether that would be any more practical for me when deploying remotely / have my friend deploy on his pc. And also would like to know how do I tag a version on my repository for setup.py to refer to it, is it simply a version control tag (hg in my case)?. Feel free to comment on any details you think are important for the starter packager :)
Thanks!
put this:
dependency_links=['https://bitbucket.org/abraneo/django-registration/get/tip.tar.gz#egg=django-registration']
in the dependency_links you have to pass a download url like that one.
"abraneo" is a guy who forked this project too, replace his name by yours.
I'm trying to convert a current Django project in development to use zc.buildout So far, I've got all the bits figured except for Haystack figured out.
The Haystack source is available on GitHub, but I don't want to force users to install git. A suitable alternative seems to be to fetch a tarball from here
That tarball contains a setuptools setup.py, and it seems like it should be so easy to get buildout to install it. Halp!
I figured this one out, without posting it to PyPI. (There is no actually tagged release version of django-haystack, so posting to to PyPI seems unclean. It's something the maintainer should and probably will handle better themselves.)
The relevant section is as follows:
[haystack]
recipe = collective.recipe.distutils
url = http://github.com/ephelon/django-haystack/tarball/master
I had to create a fork of the project to remove zip_safe=False from setup.py. Once I'd done that the above works flawlessly, even the redirect sent by the above url.
This currently works for me without forking.
[django-haystack]
recipe = zerokspot.recipe.git
repository = git://github.com/toastdriven/django-haystack.git
as_egg = true
[whoosh]
recipe = zerokspot.recipe.git
repository = git://github.com/toastdriven/whoosh.git
branch = haystacked
as_egg = true
Make sure you add the locations to your extra-paths.
Well, if you don't want to install GIT, you can't check it out. So then you have to download a release. But there aren't any. In theory, find-links directly to the distribution should work. In this case it wont, probably because you don't link to the file, but to a page that generates the file from the trunk. So that option was out.
So, you need to bribe somebody to make a release, or make one yourself. You can make a release and stick it in a file server somewhere, and then use find-links in the buildout to point to the right place.
Or, since nobody else seems to have released Haystack to PyPI, you can do it! (But be nice and tell the developers and give them manager rights to the package as well).
It seems they've fixed the package to work from the tarball. James' fork is not working right now, but you can use the same recipe passing it the standard url:
[haystack]
recipe = collective.recipe.distutils
url = http://github.com/toastdriven/django-haystack/tarball/master
This worked for me and is 100% hack free.