<RoadrunnerWMC>
mattip: ah, thank you. I thought manylinux1 was the successor to manylinux2010, but looking closer, it seems it's actually the opposite. I'll try 2010, then!
<RoadrunnerWMC>
One more quick question for now: will wheels built against PyPy 7.0 (3.5) also work on 7.1 (3.6), or do I need separate wheels for that (like with CPython)?
speeder39_ has joined #pypy
tsaka_ has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<kenaan>
arigo py3.6-sandbox-2 150338122bc4 /rpython/translator/sandbox/test/: Remove old tests
<kenaan>
arigo py3.6-sandbox-2 4b3a0b8bf44b /: Compile the sandbox with the _socket module
jacob22 has quit [Quit: Konversation terminated!]
<mattip>
RoadrunnerWMC: no, the c-extension modules are different
<RoadrunnerWMC>
Using the manylinux2010 container does let PyPy install now, though I'm having some trouble with getting it to then install Pillow. (I'm not asking for help with that -- just giving a status update.) So thanks again for that suggestion!
<kenaan>
arigo py3.6-sandbox-2 4997ac74778b /: Use the select module too
<mattip>
RoadrunnerWMC: if possible I would target a nightly release rather than 7.1.1, and pypy 7.0 is "really old" for c-extension support of most project's HEAD
<RoadrunnerWMC>
mattip: if you say so. I'll try it
<mattip>
:)
<RoadrunnerWMC>
I thought I read somewhere, though, that the official builds are done on Ubuntu, which I think would make it unlikely that they'd work on CentOS 6?
<mattip>
hmm. And additionally, pillow run pypy in their CI so pillow should not be a blocker
<RoadrunnerWMC>
Basically the Pillow issue is that there's no build on PyPI for it, so pip downloads the source release and tries to build that. Which fails because the container lacks zlib and libjpeg. Which I can't install because yum requires sudo. Which isn't available in the container.
<RoadrunnerWMC>
It's not a *hard* requirement that I get Pillow to build here, as I'm only using it for my unit tests (it's not a dependency of my package itself). But I still would like to get the unit tests running on Linux/PyPy if possible
speeder39_ has quit [Quit: Connection closed for inactivity]
<mattip>
pillow uses the multibuild system to build wheels, perhaps they could add pypy support?
<RoadrunnerWMC>
My current attempted workaround is to download/build zlib and libjpeg without sudo and then get Pillow to recognize/use those copies. But I suppose I could open an issue for that there, so this hopefully becomes less of a problem in the future
<mattip>
it seems like multibuild is close to supporting manylinux2010, which would be great news all around
<mattip>
"June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed"
jcea has joined #pypy
jcea has quit [Remote host closed the connection]
<fijal>
oh crap, that sucks
<fijal>
now we have to move
<mattip>
to ... ?
<fijal>
our own mercurial I guess?
<fijal>
maybe we can get gitlab support working
<fijal>
we can also do what we did for VR Sketch - have everything on github except the actual repo, which lives somewhere else
<ronan>
urgh, that sounds like a mess
<ronan>
if there's no good hosted Mercurial solution, I think we should just move to github
<fijal>
there is nearly no way we are going to use git
<ronan>
there is no way we're going to self-host
<fijal>
why not?
<ronan>
it's going to be a ton of work for something that's unlikely to be anywhere as usable as what we have now
<ronan>
(and Bitbucket isn't that good...)
<fijal>
why? we are self-hosting for vr sketch and it has been very little work
<fijal>
but what I'm saying is that convincing armin to use git is not going to work
<mattip>
self-hosting a repo is ok, the problem is integrating it with an issue tracker
<mattip>
and commit comment ability
Rhy0lite has joined #pypy
<mattip>
on a public repo, feedback for code is part of having a community, and really lacking on bitbucket
<fijal>
right, so it's not going to be worse
<fijal>
I agree, more or less
<fijal>
and I *like* browsing commits online
jcea has joined #pypy
<mjacob>
we can do a tool evaluation. if we find out that e.g. only commit-issue linking is missing from sourcehut, i can work with the developers to add it.
<mjacob>
same for gitlab. i'm a bit sceptical about the approach, but it could work just fine for us
<arigato>
I see the point of everybody saying "let's just switch to git like everybody else", except I really honestly dislike git after working with it for one year on vrsketch
<arigato>
it may be just me, but I had to fight against git constantly up to the point where we switched to mercurial, and had no problem since then
<arigato>
if people here really think switching to git is any kind of solution, I'll just shrug and use something like hggit on my own
<arigato>
so don't let my particular preference play a role in the answer
<mjacob>
i think that mercurial is a better fit than git for pypy and i'm willing to invest some time to improve the ecosystem to make it work better for us.
<arigato>
(I think that mercurial is more actively used than git in some entreprise domains, so bitbucket dropping support for that seems like bitbucket dropping its last major advantage over github, to me)
<Hodgestar>
I would be interested to read the deeper technical reasons behind the change. Forcing a lot of your longest standing customers to consider other options is quite a big thing to do.
<mattip>
arigato: you may want to check hggit performance on a big repo before committing to use it
<mattip>
. I just tried to clone github.com/python/cpython with it and gave up when it said 3 hours remaining
fryguybob has quit [Ping timeout: 245 seconds]
<arigato>
mattip: right, though I don't care too much if I need to wait once for the initial clone---actually if the hg->git conversion preserves the changeset hashes, which I think is possible, then I can just continue to use my existing repos
<arigato>
the main issue is that the hg->git conversion is likely to forget all branch names, and we'll end up in a mess of a git repo
<mattip>
with the helpful message "We found an error during import. We recommend restarting the import process, but if you are still having trouble contact support"
<arigato>
you're trying to import the pypy repo? good luck with that
<mjacob>
we "just" need to find a revset and a template that can be used to get an injective mapping from a subset of hg changesets to git branch names
<danchr>
there's an effort going to add support for Mercurial to GitLab called Heptapod
<_aegis_>
my input: as someone who doesn't use mercurial for anything else, I have had a lot of friction using the hg client to contribute to pypy
<nedbat>
mjacob: why do you say that hg is better for pypy than git? What about pypy makes that so?
jacob22 has joined #pypy
<_aegis_>
not just that it's unfamiliar, even after reading the pypy docs on contributing, and googling about equivalent branching workflows in mercurial, I've managed to get my local repository into undesirable states I couldn't get it out of without a re-clone or nonstandard mercurial extensions
<_aegis_>
since the repo is so big by far hg has been the biggest bottleneck for my few contributions
<_aegis_>
was much quicker to send a patch here or on the issue tracker, which is unfortunate in my eyes
<mjacob>
nedbat: in general (not just for pypy), i like the fact that the branch name is stored in every commit, instead of just on the head of the branch.
<nedbat>
mjacob: yes, that's a difference between the two that takes some getting used to
<mjacob>
nedbat: well, pypy is already used to the name-on-commit model ;)
<nedbat>
mjacob: yes
<mjacob>
nedbat: it's even more important for pypy, because there are often a lot of commits in the style of "hack around to make tests pass". without the branch name it's hard to tell which larger feature some particular commit belongs to
<tumbleweed>
that's something I often find myself doing in git repos, with a bit of git log --graph reading
<tumbleweed>
(and in github, it'll show a link to the PR that contained this commit on the commit page)
<mjacob>
tumbleweed: it's possible to work around this, but i always found that i want the hg model.
<mjacob>
i use hg in two projects (in addition to the personal ones) with very different working styles, and in both projects we wanted the branch name to be shown prominently.
<nedbat>
mjacob: how do you navigate to the commit? You're saying it's useful given a commit to know what branch it is in. Where do you get the commit from?
<tumbleweed>
a blame, usually
<mjacob>
nedbat: i was thinking about when using 'hg blame' or 'git blame'
<tumbleweed>
or a git log FILENAME
<nedbat>
hmm, i see
<mjacob>
for viewing the recent commits, it's less important, because git shows only the commits in the current branch by default
<mjacob>
another reason why i like hg more than git, is the changeset evolution concept. for pypy's current working style that doesn't matter much, though.
<mjacob>
sometimes people tell me that they defer pushing a branch in git because afterwards they shouldn't rebase it. with hg and changeset evolution that's not an issue at all. in fact, you can modify history of the same branch even on multiple clients without running into serious trouble.
<mjacob>
for my boss, the main reason for introducing hg was the availability of a gui, which can be quite helpful for browing the history.
jacob22 has joined #pypy
jacob22 has quit [Quit: Konversation terminated!]
jacob22 has joined #pypy
ajlawrence has joined #pypy
<nedbat>
mjacob: there are certainly git guis... i haven't used changeset evolution, it sounds useful.
<arigato>
storing branch names inside git commits sound difficult. even if we say that all commit messages should start with the branch name, for example, and enforce that with a push hook or something, it's going to create many tensions from other contributors
<arigato>
the alternative is to use some nonstandard way of displaying logs, together with a file that store a mapping from some changeset hashes to branch names, with the branch name being inferred for the rest of the changesets
<arigato>
if you ask me if any of this sounds like a good idea, I'd say No
<tumbleweed>
the model is different, though. A commit can be in multiple branches in git
<tumbleweed>
in hg, I think the blame will usually show a merge commit, but in git it'll take you back to the source
<mjacob>
i think "it depends" which commit is shown by the blame. but i'm not sure on what it depends.
<mjacob>
the mercurial sprint in leipzig, germany is probably on sep 7th / 8th. everyone wanting to discuss the future of pypy on mercurial will be welcome. :) https://framadate.org/jIs6Idj4r8tldJKZ
<ajlawrence>
I am pretty sure you can protect branches against forced pushes and deletion on github. You could also configure the continuous integration to look for tags on branches before allowing a merge.
<ajlawrence>
You could also get some build bot / ci system to automatically tag each commit with the branch name.
<arigato>
ajlawrence: it sounds too late to me, if this automatic tagging occurs only when someone pushes then he might push any number of changesets that logically belong to any number of branches
<arigato>
I don't know, maybe it's a workable workaround to say that all commit messages must start with [branchname] or be rejected
<mjacob>
what would be a good way to track the different possibilities we have for replacing bitbucket? a piratepad?
<arigato>
where [branchname] must be the same as in one of the parents, except when we make a new branch in which case the commit message must start with "[branchname] NEW BRANCH"
<arigato>
mjacob: +1
<arigato>
additionally, if we can enforce it, we add the condition that any git branch called "x" must be attached to a commit starting with "[x]"
<ajlawrence>
This is where protected branches come in. You cannot push directly to protected branches. They have to go through the CI system and then be merged in through a pull request.
<ajlawrence>
Or atleast that is one possibility.
<ajlawrence>
There are different degrees of protection.
<arigato>
I don't know about protected branches, can you explain what it is and how it relates?
<_aegis_>
might help to use one of the alternate ways of looking at the log
<_aegis_>
if you run one of the pretty branch viewers on a file you will see it diverge into the branch
<mjacob>
arigato: right now my internet connection is too slow for collaborative editing :) i'll probably reformat it a bit later.
<ajlawrence>
Maybe I am confused about what the problem is. I was under the impression that there was some worry about losing the branch names or the history/structure of the git repository through someone doing a git push.
<arigato>
_aegis_: the point I'd like to make is that git simply does not store enough information to recontruct the hg branch names in all cases, and I'd hate it if I have to try to second-guess git's guesses during any git bisect session, for example
<arigato>
the problem is that pypy really use branches a lot, so I'm pretty sure these ambiguous cases occur regularly
<arigato>
if you want just one example, making a branch called A from master, and later a branch called B from A, and continuing to work on both A and B---at this point, git is lost as to whether the older part of A belongs to A or B
<ajlawrence>
You are right that git would not care about the difference there
<arigato>
if additionally there are some merges between A and B, then all the part below the most recent merge is ambiguous
<ajlawrence>
My feeling is that you would have to protect branches and put additional checks in place to ensure the desired information is present.
<arigato>
I still don't understand why specific branches need to be "protected"
<ajlawrence>
You can do something called a rebase in git
<ajlawrence>
With an interactive rebase you can actually go back and edit the history, delete files out of commits or what ever you fancy
<ajlawrence>
then when you push the repository the old history of that branch is gone forever
<arigato>
yes, which means we need to weight if people are most likely nowadays to be familiar with these kind of git rewriting commands, or with basic mercurial commands. Maybe the answer nowadays is still git
<arigato>
I can definitely see myself on the complete other end of the spectrum, being used to mercurial but hating git all the way, but again I don't necessarily want that to be a stopper
<ajlawrence>
I would use what I described above as an example of why git is bad as it is possible make a mess out of the repository or destroy it without enabling some form of protection.
<tos9>
(botched rebases are generally completely reversable, so I wouldn't use that as an example personally, but I have no horse in the hg vs git race other than my sympathy for the bitbucket decision)
<kenaan>
rlamy default 3ea4a70584df /pypy/objspace/std/: Avoid RuntimeError in repr() of recursive dictviews (bpo-18533)
<mjacob>
arigato: whether we want to allow history rewriting or not is an independent question. i'm a happy everyday user of mercurial's recent history editing features. on the git side, history editing can be forbidden by a push hook.
<tos9>
I'd love to think that in 2019 every git user roughly agrees on the policy for rewriting
<tos9>
namely -- no rewriting any history that has already been pushed remotely
<kenaan>
rlamy default 863f304d4d70 /pypy/objspace/std/dictmultiobject.py: remove dead code