Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, 30 Nov 2014 22:06:03 -0500 Terry Reedy wrote: > > If the mirror experiment is successful, the devguide might be the next > experiment. It does not have any one maintainer, and *is* tied to the > tracker. But herein lies the problem with the devguide. There are 22 > issues, down just 1 from about a year ago. All but 2 are more than a > year old. Many (most?) have patches, but enough consensus for anyone to > push is hard. As with other doc issues, there is no 'test' for when a > non-trivial patch is 'good enough' and hence, in my opinion, too much > bikeshedding and pursuit of the perfect. Speaking as someone who contributed to the devguide, I think it has become good enough and have therefore largely stopped caring. Also, many requests seem to be of the "please add this thing" kind, which is a slippery slope. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-11-30, 11:18 GMT, Ben Finney wrote: > Donald Stufft writes: > >> I think there is a big difference here between using a closed source >> VCS or compiler and using a closed source code host. Namely in that >> the protocol is defined by git so switching from one host to another >> is easy. > > GitHub deliberately encourages proprietary features that create valuable > data that cannot be exported — the proprietary GitHub-specific pull > requests being a prime example. What I really don’t understand is why this discussion is hg v. GitHub, when it should be hg v. git. Particular hosting is a secondary issue and it could be GitHub or git.python.org (with some FLOSS git hosting package ... cgit/gitolite, gitorious, gitlab, etc.) or python.gitorious.org (I believe Gitorious people might be happy to host you) or whatever else. Best, Matěj ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote: > Migrating the DVCS content is usually easy. This is lovely mantra, but do you speak from your own experience? I did move rope from Bitbucket to https://github.com/python-rope and it was A LOT of work (particularly issues, existing pull requests, and other related stuff like many websites the projects holds). And rope is particularly simple (and almost dead so inactive) project. Best, Matěj ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 00:50 GMT, Donald Stufft wrote: > The only thing that is true is that git users are more likely to use the > ability to rewrite history than Mercurial users are, but you’ll typically > find that people generally don’t do this on public branches, only on private > branches. And I would add that any reasonable git repository manager (why we are talking only about GitHub as if there was no cgit, gitorious, gitlab, gitblit, etc.?) can forbid forced-push so the history could be as sacrosanct as with Mercurial. Matěj ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, 1 Dec 2014 08:46:46 +0100 Matěj Cepl wrote: > On 2014-12-01, 02:12 GMT, Pierre-Yves David wrote: > > Migrating the DVCS content is usually easy. > > This is lovely mantra, but do you speak from your own > experience? I did move rope from Bitbucket to > https://github.com/python-rope and it was A LOT of work > (particularly issues, existing pull requests, and other related > stuff like many websites the projects holds). He did say "DVCS content" (as in: stuff that's stored in git or hg), not ancillary data such as pull requests, issues, wikis and Web sites. But you're making his point: migrating a source code repository from hg to git or vice-versa is relatively easy, it's the surrounding stuff that's hard. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 02:56:22PM -0500, Donald Stufft wrote: > As I mentioned in my other email, we’re already supporting two > different tools, and it’s a hope of mine to use this as a sort of > testbed to moving the other repositories as well. If we go down this path, can we have some *concrete* and *objective* measures of success? If moving to git truly does improve things, then the move can be said to be a success. But if it makes no concrete difference, then we've wasted our time. In six months time, how will we know which it is? Can we have some concrete and objective measures of what would count as success, and some Before and After measurements? Just off the top of my head... if the number of documentation patches increases significiantly (say, by 30%) after six months, that's a sign the move was successful. It's one thing to say that using hg is discouraging contributors, and that hg is much more popular. It's another thing to say that moving to git will *actually make a difference*. Maybe all the would-be contributors using git are too busy writing kernel patches for Linus or using Node.js and wouldn't be caught dead with Python :-) With concrete and objective measures of success, you will have ammunition to suggest moving the rest of Python to git in a few years time. And without it, we'll also have good evidence that any further migration to git may be a waste of time and effort and we should focus our energy elsewhere rather than git vs hg holy wars. [...] > I also think it’s hard to look at a company like bitbucket, for > example, and say they are *better* than Github just because they > didn’t have a public and inflammatory event. We can't judge companies on what they might be doing behind closed doors, only on what we can actually see of them. Anybody might be rotten bounders and cads in private, but how would we know? It's an imperfect world and we have imperfect knowledge but still have to make a decision as best we can. > Attempting to reduce the cognitive burden for contributing and aligning > ourselves > with the most popular tools allows us to take advantage of the network effects > of these tools popularity. This can be the difference between someone with > limited > amount of time being able to contribute or not, which can make real inroads > towards > making it easier for under privileged people to contribute much more than > refusing > to use a product of one group of people over another just because the other > group > hasn’t had a public and inflammatory event. In other contexts, that could be a pretty awful excuse for inaction against the most aggregiously bad behaviour. "Sure, Acme Inc might have adulterated baby food with arsenic, but other companies might have done worse things that we haven't found out about. So we should keep buying Acme's products, because they're cheaper and that's good for the poor." Not that I'm comparing GitHub's actions with poisoning babies. What GitHub did was much worse. *wink* -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Tue, Dec 02, 2014 at 12:37:22AM +1100, Steven D'Aprano wrote: [...] > It's one thing to say that using hg is discouraging contributors, and > that hg is much more popular. /s/more/less/ -- Steven ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Joining the PEP Editors team
On Dec 01, 2014, at 03:54 PM, Chris Angelico wrote: >In response to Guido's call for volunteers, I'm offering myself as a >PEP editor. Who is in charge of this kind of thing? Who manages public >key lists etc? I can add you to the pep editors mailing list. Please send me a off-list message with your preferred email address. I'd prefer it if you GPG signed that message. See here for getting your SSH key registered such that you can make commits to the PEP repo. https://docs.python.org/devguide/faq.html#ssh Cheers, -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, Dec 1, 2014 at 12:25 AM, Ethan Furman wrote:
> One argument that keeps coming up is transferability of knowledge:
> knowing git and/or GitHub, as many seem to, it
> therefore becomes easier to commit to the Python ecosystem.
>
> What about the transferability of Python knowledge? Because I know
> Python, I can customize hg; because I know Python I
> can customize Roundup.
>
> I do not choose tools simply because they are written in Python -- I
> choose them because, being written in Python, I can
> work on them if I need to: I can enhance them, I can fix them, I can
> learn from them.
>
>
There are lots of Python tools written with Git:
* https://pypi.python.org/pypi/vcs
* https://pypi.python.org/pypi/dulwich
* https://pypi.python.org/pypi/hg-git
* http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html ("GitFS")
* https://github.com/libgit2/pygit2 (C)
* https://pypi.python.org/pypi/GitPython (Python)
* https://pypi.python.org/pypi/pyrpo (subprocess wrapper for git, hg, bzr,
svn)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum wrote: > Can we please stop the hg-vs-git discussion? We've established earlier > that the capabilities of the DVCS itself (hg or git) are not a > differentiator, and further he-said-she-said isn't going to change > anybody's opinion. > +1 from me as well. I view this as a discussion of platforms and not DVCSs. > > What's left is preferences of core developers, possibly capabilities of > the popular websites (though BitBucket vs. GitHub seems to be a wash as > well), and preferences of contributors who aren't core developers (using > popularity as a proxy). It seems the preferences of the core developers are > mixed, while the preferences of non-core contributors are pretty clear, so > we have a problem weighing these two appropriately. > > Also, let's not get distracted by the needs of the CPython repo, issue > tracker, and code review tool. Arguments about core developers vs. > contributors for CPython shouldn't affect the current discussion. > > Next, two of the three repos mentioned in Donald's PEP 481 are owned by > Brett Cannon, according to the Contact column listed on hg.python.org. I > propose to let Brett choose whether to keep these on hg.python.org, move > to BitBucket, or move to GitHub. @Brett, what say you? (Apart from "I'm > tired of the whole thread." :-) > You do one or two nice things for python-dev and you end up being saddled with them for life. ;) Sure, I can handle the devguide and devinabox decisions since someone has to and it isn't going to be more "fun" for someone else compared to me. > > The third one is the peps repo, which has [email protected] as > Contact. It turns out that Nick is by far the largest contributor (he > committed 215 of the most recent 1000 changes) so I'll let him choose. > "Perk" of all those packaging PEPs. > > Finally, I'd like to get a few more volunteers for the PEP editors list, > preferably non-core devs: the core devs are already spread too thinly, and > I really shouldn't be the one who picks new PEP numbers and checks that > PEPs are well-formed according to the rules of PEP 1. A PEP editor > shouldn't have to pass judgment on the contents of a PEP (though they may > choose to correct spelling and grammar). Knowledge of Mercurial is a plus. > :-) > And based on how Nick has been talking, will continue to be at least in the medium term. =) -Brett > > On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft wrote: > >> >> > On Nov 30, 2014, at 7:43 PM, Ben Finney >> wrote: >> > >> > Donald Stufft writes: >> > >> >> It’s not lost, [… a long, presumably-accurate discourse of the many >> >> conditions that must be met before …] you can restore it. >> > >> > This isn't the place to discuss the details of Git's internals, I think. >> > I'm merely pointing out that: >> > >> >> The important thing to realize is that a “branch” isn’t anything >> >> special in git. >> > >> > Because of that, Ethan's impression – that Git's default behaviour >> > encourages losing history (by re-writing the history of commits to be >> > other than what they were) is true, and “Git never loses history” simply >> > isn't true. >> > >> > Whether that is a *problem* is a matter of debate, but the fact that >> > Git's common workflow commonly discards information that some consider >> > valuable, is a simple fact. >> > >> > If Ethan chooses to make that a factor in his decisions about Git, the >> > facts are on his side. >> >> Except it’s not true at all. >> >> That data is all still there if you want it to exist and it’s not a real >> differentiator between Mercurial and git because Mercurial has the ability >> to do the same thing. Never mind the fact that “lose” your history makes >> it >> sound accidental instead of on purpose. It’s like saying that ``rm >> foo.txt`` >> will “lose” the data in foo.txt. So either it was a misunderstanding in >> which case I wanted to point out that those operations don’t magically >> lose >> information or it’s a purposely FUDish statement in which case I want to >> point out that the statement is inaccurate. >> >> The only thing that is true is that git users are more likely to use the >> ability to rewrite history than Mercurial users are, but you’ll typically >> find that people generally don’t do this on public branches, only on >> private >> branches. Which again doesn’t make much sense in this context since >> generally >> currently the way people are using Mercurial with CPython you’re using >> patches to transfer the changes from the contributor to the committer so >> you’re >> “losing” that history regardless. >> >> --- >> Donald Stufft >> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/guido%40python.org >> > > > > -- > --Guido van Rossum
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
As far as I'm concerned I'm just waiting for your decision now. On Mon, Dec 1, 2014 at 7:07 AM, Brett Cannon wrote: > > > On Sun Nov 30 2014 at 8:25:25 PM Guido van Rossum > wrote: > >> Can we please stop the hg-vs-git discussion? We've established earlier >> that the capabilities of the DVCS itself (hg or git) are not a >> differentiator, and further he-said-she-said isn't going to change >> anybody's opinion. >> > > +1 from me as well. I view this as a discussion of platforms and not DVCSs. > > >> >> What's left is preferences of core developers, possibly capabilities of >> the popular websites (though BitBucket vs. GitHub seems to be a wash as >> well), and preferences of contributors who aren't core developers (using >> popularity as a proxy). It seems the preferences of the core developers are >> mixed, while the preferences of non-core contributors are pretty clear, so >> we have a problem weighing these two appropriately. >> >> Also, let's not get distracted by the needs of the CPython repo, issue >> tracker, and code review tool. Arguments about core developers vs. >> contributors for CPython shouldn't affect the current discussion. >> >> Next, two of the three repos mentioned in Donald's PEP 481 are owned by >> Brett Cannon, according to the Contact column listed on hg.python.org. I >> propose to let Brett choose whether to keep these on hg.python.org, move >> to BitBucket, or move to GitHub. @Brett, what say you? (Apart from "I'm >> tired of the whole thread." :-) >> > > You do one or two nice things for python-dev and you end up being saddled > with them for life. ;) > > Sure, I can handle the devguide and devinabox decisions since someone has > to and it isn't going to be more "fun" for someone else compared to me. > > >> >> The third one is the peps repo, which has [email protected] as >> Contact. It turns out that Nick is by far the largest contributor (he >> committed 215 of the most recent 1000 changes) so I'll let him choose. >> > > "Perk" of all those packaging PEPs. > > >> >> Finally, I'd like to get a few more volunteers for the PEP editors list, >> preferably non-core devs: the core devs are already spread too thinly, and >> I really shouldn't be the one who picks new PEP numbers and checks that >> PEPs are well-formed according to the rules of PEP 1. A PEP editor >> shouldn't have to pass judgment on the contents of a PEP (though they may >> choose to correct spelling and grammar). Knowledge of Mercurial is a plus. >> :-) >> > > And based on how Nick has been talking, will continue to be at least in > the medium term. =) > > -Brett > > >> >> On Sun, Nov 30, 2014 at 4:50 PM, Donald Stufft wrote: >> >>> >>> > On Nov 30, 2014, at 7:43 PM, Ben Finney >>> wrote: >>> > >>> > Donald Stufft writes: >>> > >>> >> It’s not lost, [… a long, presumably-accurate discourse of the many >>> >> conditions that must be met before …] you can restore it. >>> > >>> > This isn't the place to discuss the details of Git's internals, I >>> think. >>> > I'm merely pointing out that: >>> > >>> >> The important thing to realize is that a “branch” isn’t anything >>> >> special in git. >>> > >>> > Because of that, Ethan's impression – that Git's default behaviour >>> > encourages losing history (by re-writing the history of commits to be >>> > other than what they were) is true, and “Git never loses history” >>> simply >>> > isn't true. >>> > >>> > Whether that is a *problem* is a matter of debate, but the fact that >>> > Git's common workflow commonly discards information that some consider >>> > valuable, is a simple fact. >>> > >>> > If Ethan chooses to make that a factor in his decisions about Git, the >>> > facts are on his side. >>> >>> Except it’s not true at all. >>> >>> That data is all still there if you want it to exist and it’s not a real >>> differentiator between Mercurial and git because Mercurial has the >>> ability >>> to do the same thing. Never mind the fact that “lose” your history makes >>> it >>> sound accidental instead of on purpose. It’s like saying that ``rm >>> foo.txt`` >>> will “lose” the data in foo.txt. So either it was a misunderstanding in >>> which case I wanted to point out that those operations don’t magically >>> lose >>> information or it’s a purposely FUDish statement in which case I want to >>> point out that the statement is inaccurate. >>> >>> The only thing that is true is that git users are more likely to use the >>> ability to rewrite history than Mercurial users are, but you’ll typically >>> find that people generally don’t do this on public branches, only on >>> private >>> branches. Which again doesn’t make much sense in this context since >>> generally >>> currently the way people are using Mercurial with CPython you’re using >>> patches to transfer the changes from the contributor to the committer so >>> you’re >>> “losing” that history regardless. >>> >>> --- >>> Donald Stufft >>> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA >>> >>> ___
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 2014-12-01, 07:43 GMT, Donald Stufft wrote: >> I do not choose tools simply because they are written in >> Python -- I choose them because, being written in Python, I >> I can work on them if I need to: I can enhance them, I can >> fix them, I can learn from them. > > Git uses the idea of small individual commands that do small things, > so you can write your own commands that work on text streams to > extend git and you can even write those in Python. I really really dislike this Mercurial propaganda for two reasons: a) obviously you are right ... git is a complete tool box for building your own tools in the best UNIX™ traditions. Each of has a ton of third-party (or our own) tools using git plumbing. (Is there a Mercurial equivalent of git-filter-branch? Can http://mercurial.selenic.com/wiki/ConvertExtension do the same as git-filter-branch?) b) it completely ignores existence of three (3) independent implementations of git format/protocol (also jgit and libgit2). How does VisualStudio/Eclipse/NetBeans/etc. support for hg works? Does it use a library or just runs hg binary in a subprocess (a thing which by the hg authors is Mercurial not designed to do)? Best, Matěj ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Here's a roundup of tools links, to make sure we're all on the same page:
Git HG Rosetta Stone
===
https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone
BugWarrior
===
BugWarrior works with many issue tracker APIs
https://warehouse.python.org/project/bugwarrior/
bugwarrior is a command line utility for updating your local taskwarrior
> database from your forge issue trackers.
> It currently supports the following remote resources:
>
>- github (api v3)
>- bitbucket
>- trac
>- bugzilla
>- megaplan
>- teamlab
>- redmine
>- jira
>- activecollab (2.x and 4.x)
>- phabricator
>
> [...]
DVCS Interaction
Hg <-> Git
* https://warehouse.python.org/project/hg-git/ (dulwich)
* hg-github https://github.com/stephenmcd/hg-github
Git <-> Hg
--
* https://pypi.python.org/pypi/git-remote-hg/
* https://github.com/felipec/git-remote-hg
Python <-> Hg
---
| Wikipedia: https://en.wikipedia.org/wiki/Mercurial
| Homepage: http://hg.selenic.org/
| Docs: http://mercurial.selenic.com/guide
| Docs: http://hgbook.red-bean.com/
| Source: hg http://selenic.com/hg
| Source: hg http://hg.intevation.org/mercurial/crew
* http://evolution.experimentalworks.net/doc/user-guide.html
* (growing list of included extensions)
Python <-> Git
--
* GitPython, pygit2 (libgit2), dulwich
* https://github.com/libgit2/pygit2 (libgit2)
* https://pythonhosted.org/GitPython/ (Python)
* https://github.com/jelmer/dulwich (Python)
*
http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#installing-dependencies
GitHub -> BitBucket
-
* https://bitbucket.org/ZyX_I/gibiexport
Sphinx Documentation
* http://read-the-docs.readthedocs.org/en/latest/webhooks.html
* https://github.com/yoloseem/awesome-sphinxdoc
* changelogs, charts, csv, ipython, %doctest_mode
Is there an issue ticket or a wiki page that supports
Markdown/ReStructuredText,
where I could put this? Which URI do we assign to this artifact?
On Mon, Dec 1, 2014 at 8:37 AM, Wes Turner wrote:
>
>
> On Mon, Dec 1, 2014 at 12:25 AM, Ethan Furman wrote:
>
>> One argument that keeps coming up is transferability of knowledge:
>> knowing git and/or GitHub, as many seem to, it
>> therefore becomes easier to commit to the Python ecosystem.
>>
>> What about the transferability of Python knowledge? Because I know
>> Python, I can customize hg; because I know Python I
>> can customize Roundup.
>>
>> I do not choose tools simply because they are written in Python -- I
>> choose them because, being written in Python, I can
>> work on them if I need to: I can enhance them, I can fix them, I can
>> learn from them.
>>
>>
> There are lots of Python tools written with Git:
>
> * https://pypi.python.org/pypi/vcs
> * https://pypi.python.org/pypi/dulwich
> * https://pypi.python.org/pypi/hg-git
> * http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html
> ("GitFS")
> * https://github.com/libgit2/pygit2 (C)
> * https://pypi.python.org/pypi/GitPython (Python)
> * https://pypi.python.org/pypi/pyrpo (subprocess wrapper for git, hg,
> bzr, svn)
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/01/2014 01:05 PM, Matěj Cepl wrote: > On 2014-12-01, 07:43 GMT, Donald Stufft wrote: >>> I do not choose tools simply because they are written in >>> Python -- I choose them because, being written in Python, I >>> I can work on them if I need to: I can enhance them, I can >>> fix them, I can learn from them. >> >> Git uses the idea of small individual commands that do small things, >> so you can write your own commands that work on text streams to >> extend git and you can even write those in Python. > > I really really dislike this Mercurial propaganda for two > reasons: > > a) obviously you are right ... git is a complete tool box for >building your own tools in the best UNIX™ traditions. Each of >has a ton of third-party (or our own) tools using git >plumbing. (Is there a Mercurial equivalent of >git-filter-branch? Can >http://mercurial.selenic.com/wiki/ConvertExtension do the >same as git-filter-branch?) > b) it completely ignores existence of three (3) independent >implementations of git format/protocol (also jgit and >libgit2). How does VisualStudio/Eclipse/NetBeans/etc. support >for hg works? Does it use a library or just runs hg binary in >a subprocess (a thing which by the hg authors is Mercurial >not designed to do)? Please at least try to get your facts right. """ For the vast majority of third party code, the best approach is to use Mercurial's published, documented, and stable API: the command line interface. """ http://mercurial.selenic.com/wiki/MercurialApi Georg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/01/2014 08:42 AM, Wes Turner wrote: > > Here's a roundup of tools links, to make sure we're all on the same page: Thanks! -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]
M. Cepl asked: > What I really don't understand is why this discussion is hg v. > GitHub, when it should be hg v. git. Particular hosting is > a secondary issue I think even the proponents concede that git isn't better enough to justify a switch in repositories. They do claim that GitHub (the whole environment; not just the hosting) is so much better that a switch to GitHub is justified. Github + hg offers far fewer benefits than Github + git, so also switching to git is part of the price. Whether that is an intolerable markup or a discount is disputed, as are the value of several other costs and benefits. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]
On Mon, Dec 1, 2014 at 12:37 PM, Jim J. Jewett wrote: > I think even the proponents concede that git isn't better enough > to justify a switch in repositories. There are also many who find the Bitbucket tools more usable than the Github tools. I'm not aware of any functional differences (though I don't often use Github myself), but the Bitbucket UIs have a much cleaner feel to them. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]
> hg vs Github At best, this is apples to oranges in comparing a DVCS to a platform, or was the intention to change the subject to "hg vs git"? If so, then it's promoting a developer tool war in the same vein as the never ending vim vs emacs and will likely only result in continued dissension. IMHO, there's really no point in continuing this discussion past decisions to be made by a select few in the thread discussing PEP 481. On Mon, Dec 1, 2014 at 9:56 AM, Fred Drake wrote: > On Mon, Dec 1, 2014 at 12:37 PM, Jim J. Jewett wrote: >> I think even the proponents concede that git isn't better enough >> to justify a switch in repositories. > > There are also many who find the Bitbucket tools more usable than the > Github tools. > > I'm not aware of any functional differences (though I don't often use > Github myself), but the Bitbucket UIs have a much cleaner feel to > them. > > > -Fred > > -- > Fred L. Drake, Jr. > "A storm broke loose in my mind." --Albert Einstein > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/demianbrecht%40gmail.com -- Demian Brecht https://demianbrecht.github.io https://github.com/demianbrecht ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
Hi! On Mon, Dec 01, 2014 at 10:42:16AM -0600, Wes Turner wrote: > Here's a roundup of tools links, to make sure we're all on the same page: Very nice! > Is there an issue ticket or a wiki page that supports > Markdown/ReStructuredText, > where I could put this? Which URI do we assign to this artifact? There are already pages https://wiki.python.org/moin/Git and https://wiki.python.org/moin/Mercurial . You can create an additional page and reference it on that pages. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On 12/1/2014 11:42 AM, Wes Turner wrote: Here's a roundup of tools links, to make sure we're all on the same page: Git HG Rosetta Stone === https://github.com/sympy/sympy/wiki/Git-hg-rosetta-stone#rosetta-stone BugWarrior === BugWarrior works with many issue tracker APIs https://warehouse.python.org/project/bugwarrior/ bugwarrior is a command line utility for updating your local taskwarrior database from your forge issue trackers. It currently supports the following remote resources: * github (api v3) * bitbucket * trac * bugzilla * megaplan * teamlab * redmine * jira * activecollab (2.x and 4.x) * phabricator [...] DVCS Interaction Hg <-> Git * https://warehouse.python.org/project/hg-git/ (dulwich) * hg-github https://github.com/stephenmcd/hg-github Git <-> Hg -- * https://pypi.python.org/pypi/git-remote-hg/ * https://github.com/felipec/git-remote-hg Python <-> Hg --- | Wikipedia: https://en.wikipedia.org/wiki/Mercurial | Homepage: http://hg.selenic.org/ | Docs: http://mercurial.selenic.com/guide | Docs: http://hgbook.red-bean.com/ | Source: hg http://selenic.com/hg | Source: hg http://hg.intevation.org/mercurial/crew * http://evolution.experimentalworks.net/doc/user-guide.html * (growing list of included extensions) Python <-> Git -- * GitPython, pygit2 (libgit2), dulwich * https://github.com/libgit2/pygit2 (libgit2) * https://pythonhosted.org/GitPython/ (Python) * https://github.com/jelmer/dulwich (Python) * http://docs.saltstack.com/en/latest/topics/tutorials/gitfs.html#installing-dependencies GitHub -> BitBucket - * https://bitbucket.org/ZyX_I/gibiexport Sphinx Documentation * http://read-the-docs.readthedocs.org/en/latest/webhooks.html * https://github.com/yoloseem/awesome-sphinxdoc * changelogs, charts, csv, ipython, %doctest_mode Is there an issue ticket or a wiki page that supports https://wiki.python.org/moin/ Markdown/ReStructuredText, whoops, I am not sure what moin uses. where I could put this? Which URI do we assign to this artifact? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Mon, Dec 01, 2014 at 03:52:21PM -0500, Terry Reedy wrote: > On 12/1/2014 11:42 AM, Wes Turner wrote: > >Is there an issue ticket or a wiki page that supports > > https://wiki.python.org/moin/ > > >Markdown/ReStructuredText, > > whoops, I am not sure what moin uses. Let's see... https://wiki.python.org/moin/?action=raw Seems like reST. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?
On Mon, Dec 1, 2014 at 4:06 AM, Guido van Rossum wrote: > On Sun, Nov 30, 2014 at 5:42 PM, Nathaniel Smith wrote: >> >> On Mon, Dec 1, 2014 at 1:27 AM, Guido van Rossum wrote: >> > Nathaniel, did you look at Brett's LazyLoader? It overcomes the subclass >> > issue by using a module loader that makes all modules instances of a >> > (trivial) Module subclass. I'm sure this approach can be backported as >> > far >> > as you need to go. >> >> The problem is that by the time your package's code starts running, >> it's too late to install such a loader. Brett's strategy works well >> for lazy-loading submodules (e.g., making it so 'import numpy' makes >> 'numpy.testing' available, but without the speed hit of importing it >> immediately), but it doesn't help if you want to actually hook >> attribute access on your top-level package (e.g., making 'numpy.foo' >> trigger a DeprecationWarning -- we have a lot of stupid exported >> constants that we can never get rid of because our rules say that we >> have to deprecate things before removing them). >> >> Or maybe you're suggesting that we define a trivial heap-allocated >> subclass of PyModule_Type and use that everywhere, as a >> quick-and-dirty way to enable __class__ assignment? (E.g., return it >> from PyModule_New?) I considered this before but hesitated b/c it >> could potentially break backwards compatibility -- e.g. if code A >> creates a PyModule_Type object directly without going through >> PyModule_New, and then code B checks whether the resulting object is a >> module by doing isinstance(x, type(sys)), this will break. (type(sys) >> is a pretty common way to get a handle to ModuleType -- in fact both >> types.py and importlib use it.) So in my mind I sorta lumped it in >> with my Option 2, "minor compatibility break". OTOH maybe anyone who >> creates a module object without going through PyModule_New deserves >> whatever they get. > > > Couldn't you install a package loader using some install-time hook? > > Anyway, I still think that the issues with heap types can be overcome. Hm, > didn't you bring that up before here? Was the conclusion that it's > impossible? I've brought it up several times but no-one's really discussed it :-). I finally attempted a deep dive into typeobject.c today myself. I'm not at all sure I understand the intricacies correctly here, but I *think* __class__ assignment could be relatively easily extended to handle non-heap types, and in fact the current restriction to heap types is actually buggy (IIUC). object_set_class is responsible for checking whether it's okay to take an object of class "oldto" and convert it to an object of class "newto". Basically it's goal is just to avoid crashing the interpreter (as would quickly happen if you e.g. allowed "[].__class__ = dict"). Currently the rules (spread across object_set_class and compatible_for_assignment) are: (1) both oldto and newto have to be heap types (2) they have to have the same tp_dealloc (3) they have to have the same tp_free (4) if you walk up the ->tp_base chain for both types until you find the most-ancestral type that has a compatible struct layout (as checked by equiv_structs), then either (4a) these ancestral types have to be the same, OR (4b) these ancestral types have to have the same tp_base, AND they have to have added the same slots on top of that tp_base (e.g. if you have class A(object): pass and class B(object): pass then they'll both have added a __dict__ slot at the same point in the instance struct, so that's fine; this is checked in same_slots_added). The only place the code assumes that it is dealing with heap types is in (4b) -- same_slots_added unconditionally casts the ancestral types to (PyHeapTypeObject*). AFAICT that's why step (1) is there, to protect this code. But I don't think the check actually works -- step (1) checks that the types we're trying to assign are heap types, but this is no guarantee that the *ancestral* types will be heap types. [Also, the code for __bases__ assignment appears to also call into this code with no heap type checks at all.] E.g., I think if you do class MyList(list): __slots__ = () class MyDict(dict): __slots__ = () MyList().__class__ = MyDict() then you'll end up in same_slots_added casting PyDict_Type and PyList_Type to PyHeapTypeObjects and then following invalid pointers into la-la land. (The __slots__ = () is to maintain layout compatibility with the base types; if you find builtin types that already have __dict__ and weaklist and HAVE_GC then this example should still work even with perfectly empty subclasses.) Okay, so suppose we move the heap type check (step 1) down into same_slots_added (step 4b), since AFAICT this is actually more correct anyway. This is almost enough to enable __class__ assignment on modules, because the cases we care about will go through the (4a) branch rather than (4b), so the heap type thing is irrelevant. The remaining problem is the requirement that bot
[Python-Dev] LTTng-UST support for CPython
Here is a working prototype for CPython to record all function call/return using LTTng-UST, a fast tracer. https://github.com/giraldeau/python-profile-ust However, there are few issues and questions: - I was not able to get PyTrace_EXCEPTION using "raise" or other error conditions. How can we trigger this event in Python code (PyTrace_C_EXCEPTION works)? - How could be the best way to get the full name of an object (such as package, module, class and function). Maybe it's too Java-ish, and it is better to record file/lineno instead? - On the C-API side: I did a horrible and silly function show_type() to run every Py*_Check() to determine the type of a PyObject *. What would be the sane way to do that? Your comments are very valuable. Thanks! Francis ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?
On Mon, Dec 1, 2014 at 1:38 PM, Nathaniel Smith wrote: > On Mon, Dec 1, 2014 at 4:06 AM, Guido van Rossum wrote: > > On Sun, Nov 30, 2014 at 5:42 PM, Nathaniel Smith wrote: > >> > >> On Mon, Dec 1, 2014 at 1:27 AM, Guido van Rossum > wrote: > >> > Nathaniel, did you look at Brett's LazyLoader? It overcomes the > subclass > >> > issue by using a module loader that makes all modules instances of a > >> > (trivial) Module subclass. I'm sure this approach can be backported as > >> > far > >> > as you need to go. > >> > >> The problem is that by the time your package's code starts running, > >> it's too late to install such a loader. Brett's strategy works well > >> for lazy-loading submodules (e.g., making it so 'import numpy' makes > >> 'numpy.testing' available, but without the speed hit of importing it > >> immediately), but it doesn't help if you want to actually hook > >> attribute access on your top-level package (e.g., making 'numpy.foo' > >> trigger a DeprecationWarning -- we have a lot of stupid exported > >> constants that we can never get rid of because our rules say that we > >> have to deprecate things before removing them). > >> > >> Or maybe you're suggesting that we define a trivial heap-allocated > >> subclass of PyModule_Type and use that everywhere, as a > >> quick-and-dirty way to enable __class__ assignment? (E.g., return it > >> from PyModule_New?) I considered this before but hesitated b/c it > >> could potentially break backwards compatibility -- e.g. if code A > >> creates a PyModule_Type object directly without going through > >> PyModule_New, and then code B checks whether the resulting object is a > >> module by doing isinstance(x, type(sys)), this will break. (type(sys) > >> is a pretty common way to get a handle to ModuleType -- in fact both > >> types.py and importlib use it.) So in my mind I sorta lumped it in > >> with my Option 2, "minor compatibility break". OTOH maybe anyone who > >> creates a module object without going through PyModule_New deserves > >> whatever they get. > > > > > > Couldn't you install a package loader using some install-time hook? > > > > Anyway, I still think that the issues with heap types can be overcome. > Hm, > > didn't you bring that up before here? Was the conclusion that it's > > impossible? > > I've brought it up several times but no-one's really discussed it :-). > That's because nobody dares to touch it. (Myself included -- I increased the size of typeobject.c from ~50 to ~5000 lines in a single intense editing session more than a decade ago, and since then it's been basically unmaintainable. :-( > I finally attempted a deep dive into typeobject.c today myself. I'm > not at all sure I understand the intricacies correctly here, but I > *think* __class__ assignment could be relatively easily extended to > handle non-heap types, and in fact the current restriction to heap > types is actually buggy (IIUC). > > object_set_class is responsible for checking whether it's okay to take > an object of class "oldto" and convert it to an object of class > "newto". Basically it's goal is just to avoid crashing the interpreter > (as would quickly happen if you e.g. allowed "[].__class__ = dict"). > Currently the rules (spread across object_set_class and > compatible_for_assignment) are: > > (1) both oldto and newto have to be heap types > (2) they have to have the same tp_dealloc > (3) they have to have the same tp_free > (4) if you walk up the ->tp_base chain for both types until you find > the most-ancestral type that has a compatible struct layout (as > checked by equiv_structs), then either >(4a) these ancestral types have to be the same, OR >(4b) these ancestral types have to have the same tp_base, AND they > have to have added the same slots on top of that tp_base (e.g. if you > have class A(object): pass and class B(object): pass then they'll both > have added a __dict__ slot at the same point in the instance struct, > so that's fine; this is checked in same_slots_added). > > The only place the code assumes that it is dealing with heap types is > in (4b) -- same_slots_added unconditionally casts the ancestral types > to (PyHeapTypeObject*). AFAICT that's why step (1) is there, to > protect this code. But I don't think the check actually works -- step > (1) checks that the types we're trying to assign are heap types, but > this is no guarantee that the *ancestral* types will be heap types. > [Also, the code for __bases__ assignment appears to also call into > this code with no heap type checks at all.] E.g., I think if you do > > class MyList(list): > __slots__ = () > > class MyDict(dict): > __slots__ = () > > MyList().__class__ = MyDict() > > then you'll end up in same_slots_added casting PyDict_Type and > PyList_Type to PyHeapTypeObjects and then following invalid pointers > into la-la land. (The __slots__ = () is to maintain layout > compatibility with the base types; if you find builtin types that > already have __dict__ an
Re: [Python-Dev] LTTng-UST support for CPython
On Mon, Dec 1, 2014 at 5:48 PM, Francis Giraldeau < [email protected]> wrote: > - On the C-API side: I did a horrible and silly function show_type() to > run every Py*_Check() to determine the type of a PyObject *. What would be > the sane way to do that? Questions like this are better asked on a users' forum, but you can get the type name from a python object as follows: Py_TYPE(obj)->tp_name ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github
On Sun, Nov 30, 2014 at 10:25 AM, Donald Stufft wrote: > > On Nov 30, 2014, at 1:05 PM, Guido van Rossum wrote: > > I don't feel it's my job to accept or reject this PEP, but I do have an > opinion. > > > So here’s a question. If it’s not your job to accept or reject this PEP, > whose is it? This is probably an issue we’re never going to get actual > consensus on so unless there is an arbitrator of who gets to decide I feel > it’s probably a waste of my time to try and convince absolutely *everyone*. > I saved this question. I still don't know who should accept or reject the PEP. I tried to get out of it by asking Brett for the two repos he "owns", but he hasn't stated his preference (though he did acknowledge the responsibility). If it were really up to me I'd switch all "minor" repos to GitHub, but I feel I've run into sufficient opposition (most vocally from Nick) that I think "status quo wins" applies. I think Nick previously wanted to switch to BitBucket -- if he hasn't hardened his position I say we should do that. But if he no longer wants that, I have stopped caring after the 200th message. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
