search

pytest-dev / pytest

The pytest framework makes it easy to write small tests, yet scales to support complex functional testing
https://pytest.org
MIT License
11.98k stars 2.66k forks source link

Move pytest to Github #699

Closed pytestbot closed 9 years ago

pytestbot commented 9 years ago

Originally reported by: Leonardo Santagada (BitBucket: santagada, GitHub: santagada)

Why isn't pytest on github?

There is no explanation anywhere about why not use git/github so I thought it is a good idea to have this explanation here and maybe moved to a faq on the site or something.

I don't really want to force anyone to move, but I would guess that there more people like me that would like to know if there is any advantages for the project in being on bitbucket.

pytestbot commented 9 years ago

Original comment by Floris Bruynooghe (BitBucket: flub, GitHub: flub):

There has been some discussion about a move to git/github as this comes up regularly. For me personally the short summary boils down to:

  1. A move causes some amount of pain and work for no real (technical) improvements.
  2. I dislike a (in this case github) monoculture.

One can obviously argue over these things for hours, it's never black-and-white. For now it seems the status-quo is just fine and some py.test repositories (including py.test itself) are hosted on bitbucket at https://bitbucket.org/pytest-dev while some (mostly plugins) are hosted on github at https://github.com/pytest-dev.

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

to be honest, there ARE technical improvements:

pytestbot commented 9 years ago

Original comment by Leonardo Santagada (BitBucket: santagada, GitHub: santagada):

Seeing that the month of adopting pytest is here it could be a great oportunity to give the project more visibility and possible involvement from the python community as a whole. Being more open to contribution is hard work, so some friction is expected.

pytestbot commented 9 years ago

Original comment by Ivan Smirnov (BitBucket: aldanor, GitHub: aldanor):

There are obvious benefits:

And then there are subjective questionable advantages of GitHub over BitBucket like GH being less ugly and having better UI in general which I personally agree with.

Porting the git repo itself is extremely trivial; moving issues can be done via a script like this: https://github.com/vbabiy/bitbucket_issue_migration

In fact, it takes much longer to discuss it than to just do it (given everyone agrees) :)

pytestbot commented 9 years ago

Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):

I personally prefer GitHub over bitbucket for the reasons people mentioned, so I would be a +1 in this effort if everyone agreed.

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

guys, there is a button 'vote' - let's use it :)

pytestbot commented 9 years ago

Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):

Hehehe! :)

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff

being able to keep history clear (git rebase for feature branches)

Mercurial can do rebase of branches too.

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

you probably mean bookmarks

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff And named branches too.

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

if you mean evolve, i think bb does not support this

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff I meant rebase extension

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

cool, but did you check that it works with bb?

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff You just rebase the stuff and then push to Bitbucket, that's it

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

in theory that is? can you draft the sequence of commands maybe?

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff Can you fork this repo and make a PR from a named branch to default?

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff

  1. Fork repo
  2. Make changes in default branch
  3. Make PR from default to default

  4. If default branch of original repo was diverged do this:

    hg pull -r default --rebase --update original_repo
hg push --force --new-branch fork_repo

    Strip redundant changesets from your fork from settings menu.

  5. Update your PR.
  6. Hooray - when maintainer of original repo will merge your PR, the history will remain linear.
pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

nice! but that's NOT the rebase of the named branch!

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff Who cares? History is linear, everybody happy.

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

this 'approach' leads to constant creation of new named branches during the work on PR to linearize the history or to use multiple heads on default branch both are ugly

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

No, you just work on default, update & rebase it occasionally to keep in sync with original default, and then press buttons "edit" and "update" in PR interface.

By the way, does GitHub PRs work differently in that matter?

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

right, so no branching at all then :) works of course, as if we cannot solve the problem, we can pretend it's not there.

github does nothing special about PR, it just follows the git flow: feature branches, which can be rebased and pushed with forcing the history, nothing needs to be done on the web ui for that

git checkout

git rebase origin/master -i

git push origin -f

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

right, so no branching at all then :) works of course, as if we cannot solve the problem, we can pretend it's not there.

As in GitHub ;)

In Bitbucket you need to just do additional move and update PR manually in UI after push. So they are identical in that matter.

pytestbot commented 9 years ago

Original comment by Anatoly Bubenkov (BitBucket: bubenkoff, GitHub: bubenkoff):

not at all, because you can have multiple feature branches with git and github, and single master 'feature' branch with hg and bb

pytestbot commented 9 years ago

Original comment by Leonardo Santagada (BitBucket: santagada, GitHub: santagada):

Let's not fight over SCM, I still think the most important thing about the change is to make the project more visible and lower friction for people to start contributing to it. Everyone is used to github, and projects there have many times more stars, pull-requests, contributors.

pytestbot commented 9 years ago

Original comment by Andrew Pashkin (BitBucket: andrew_pashkin, GitHub: andrew_pashkin):

@bubenkoff

not at all, because you can have multiple feature branches with git and github, and single master 'feature' branch with hg and bb

Can you write step by step what can not be done in Bitbucket and Mercurial?

pytestbot commented 9 years ago

Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):

I also think that one of the main reasons would be the tools available for GitHub.

pytestbot commented 9 years ago

Original comment by Floris Bruynooghe (BitBucket: flub, GitHub: flub):

So as I might be seen as being mildly against this (which I was at initiall) let me state here that I've changed my opinion and am now mildly in favour of this. This is not because I no longer like hg, it is still my preferred SCM. It is mostly because:

  1. Bitbucket's support for hg is pretty bad, good hg workflows are awkward (e.g. bookmarks, stripping, etc)
  2. py.test's dev guide follows a very sub-optimal-for-hg git-inspired workflow (i.e. named branches), partially caused by bitbucket's poor hg support.
  3. People just seem to just want/expect the github/bitbucket workflows instead of what one can actually do with a DVCS
pytestbot commented 9 years ago

Original comment by Bruno Oliveira (BitBucket: nicoddemus, GitHub: nicoddemus):

Hi @flub,

... instead of what one can actually do with a DVCS

Could you elaborate on that a bit, please?

My understanding about the sub-optimal-for-hg support lies on the fact that named branches are permanent repository artifacts, while bookmarks are not and are more suitable for PRs, am I correct?

(It's not my objective here to start any SCM flame war, I'm legitimately interested about your 3rd point)

pytestbot commented 9 years ago

Original comment by Holger Peters (BitBucket: HolgerPeters, GitHub: HolgerPeters):

I think the discussion here is missing the point a bit. Of course both Git and Mercurial are feature complete enough, that they can serve as VCS for a project like pytest. And Bitbucket and Github are good enough proprietary tools to do open source development on them.

So I think this discussion is rather about the question of reaching possible contributors, a question of visibility and how low of a threshold it should be for people to send their pull requests. Git is magnitudes more popular nowadays, my feeling is that Mercurial is popular with people who moved away early from SVN, and git is popular with late-DVCS adpoters as well as new devs who recently started programming.

pytestbot commented 9 years ago

Original comment by Florian Bruhin (BitBucket: The-Compiler, GitHub: The-Compiler):

I completely agree with Holger - yesterday I did my first contribution and tried searching for something like "How to make a contribution on Bitbucket for Git users" - I failed to find anything (except GitConcepts in the Mercurial wiki, which was helpful). Staying in my comfort zone I decided to just push to the default branch in my fork and make the PR to that instead of creating a feature branch.

As already mentioned, GitHub also allows pytest to use Travis, which is awesome. Getting some immediate feedback on pullrequests would be really helpful as a first-time contributor.

In the end I guess it boils down to what core contributors/maintainers think about Git and GitHub - if they strongly prefer to keep pytest on Bitbucket, then the discussion is moot.

pytestbot commented 9 years ago

Original comment by Floris Bruynooghe (BitBucket: flub, GitHub: flub):

In reply to @nicoddemus's question I'll try to clarify (but please let's not have any further discussion of SCMs here).

When git and hg where created there was no central website with repositories, there was the idea that you could create new repos all the time and could just abandon them. Likewise you can easily share bundles and patches etc to submit requests. But then github/bitbucket made the stable repo location assumption which makes many of the DVCS things awkward in a way. There are probably many reasons why people started using them, code commenting on pull requests probably being a major reason.

pytestbot commented 9 years ago

Original comment by Ionel Cristian Mărieș (BitBucket: ionelmc, GitHub: ionelmc):

Are we on GitHub yet? :grin:

pytestbot commented 9 years ago

Original comment by Ivan Smirnov (BitBucket: aldanor, GitHub: aldanor):

One more important point for GitHub -- Bitbucket doesn't have a proper in-repository code search, this is quite horrible (correct me if I've missed something?). I have to clone a repo to search a single symbol in it? For me, this would be a reason good enough to move asap.

bubenkoff commented 9 years ago

@nicoddemus you did a great job!

pytestbot commented 9 years ago

Thanks! :smile:

Themanwithoutaplan commented 9 years ago

Just for the record, I've yet to see any compelling reasons for Github over BitBucket. Travis can easily be run using a hg-git as can pretty much every other service. Bitbucket's ecosystem, via Atlassian, is arguably richer. If people are incapable of contributing to a project because it's not on Github then their contributions are unlikely to be any good.

And, personally, I find Github's UI reminds me of nursery school. But these things are intensely personal.

Still, what's done is done.

RonnyPfannschmidt commented 9 years ago

in general terms bitbucket is much worse in terms of ui, contributor turnaround and sane tooling

we have no hard data, but its what we perceived in anecdotes over the last few months before and after the switch

we would generally prefer hg, but bitbucket currently is a a reason to leave behind the better tool for a better surrounding setup

github did perfectly put itself into a market position of being a opensource hub while bitbucket was going for "killing" hg instead

even i (who is the main proponent for staying on hg) can easily agree on github being better than bitbucket

Themanwithoutaplan commented 9 years ago

I didn't want to warm up an old discussion: what's done is done.

I'm pretty opinionated on UI but it's best to leave it to personal preferences. I don't understand the tooling arguments, maybe because we run our own Jenkins for CI.

I suspect what a lot of people don't know, however, is that Atlassian provides free JIRA instances for open source projects.

hpk42 commented 9 years ago

FWIW my 2cents: i certainly don't see the github UI as superior to bitbucket. I am rather missing some things like voting and agree with @Themanwithoutaplan that the github UI is unneccessarily flashy in sokme places. I do appreciate automatic PR testing which we didn't have with BB (but maybe it could have been done). Also it seems more people are familiar with github workings which is a bit of a plus although i generally am skeptical of contributing to furthering monopolies.

warsaw commented 9 years ago

On Jul 14, 2015, at 12:59 PM, hpk42 wrote:

I do appreciate automatic PR testing which we didn't have with BB (but maybe it could have been done). Also it seems more people are familiar with github workings which is a bit of a plus although i generally am skeptical of contributing to furthering monopolies.

Not that my opinion counts for anything, but we've moved Mailman 3 to gitlab, and I've moved several of my personal projects there. It's a nice git hosting option, it's free software (the community edition is anyway), and does have some CI integration (see the Mailman project for some details). It may not be as feature full as github currently, but it's completely usable and easy, so we're happy with it.