Log file Viewer
#pypa-dev logs for Thursday the 28th of January, 2016
[12:19:03] <Ivo> I was just thinking, pypi/packaging doesn't have any concept of a key trust system right
[12:44:53] <dstufft> I do "Released vWhatever" on the first line, then duplicate the changelog in the body
[12:46:44] <Ivo> consider noting that in https://pip.pypa.io/en/stable/development/#release-process ?
[13:36:21] <Ivo> I'm sorry, I should've stopped and checked build went through on a pushed dev branch after updating setuptools 19.6
[15:07:08] <jaraco> You need ‘jaraco.packaging’ installed. Also, you have to be working from an hg checkout.
[17:16:32] <jaraco> I’d love to move to a setuptools_scm-based implementation, but I’m worried about compatibility, especially in bootstrapping… and I don’t want to open that can of worms while setuptools is unstable (which it is right now).
[17:17:08] <dstufft> jaraco: I kind of want a setuptools-scm like thing for pip, but only in development, it should emit a sdist without any setup_requires :]
[17:21:44] <jaraco> Right now, setup_requires is the best implementation available. I’m hoping my work or rwt will result in some techniques that will make things like setup_requires so painless that it can be used with impunity.
[17:23:17] <jaraco> But thinking about your goals, dstufft, isn’t what you describe - emitting an sdist without setup_requires - already met by wheel dists?
[17:24:33] <dstufft> once you've generated the sdist, the version should no longer be dynamic, a sdist has a singular version, known at generation time.
[17:25:04] <jaraco> And pje gave some advice that it essentially couldn’t be done with the metadata as it’s currently represented.
[17:25:23] <Ivo> dstufft: setup_requires = ['setuptools_scm'] if '* develop' in subprocess.check_output('git branch -l'.split()) else []
[17:26:07] <dstufft> jaraco: I think PJE is wrong on that :] it shouldn't be super hard to do, I just havne't motivated myself ot do it
[17:27:00] <Ivo> well if we managed to finish pep 426 we might be able to start putting static metadata in sdists, I thought was the eventual plan
[17:30:32] <Ivo> jaraco: you should make a dev-requirements.txt for setuptools, with jaraco.packaging & sphinx & twine in it 'n stuff
[17:31:17] <jaraco> Except you don’t need those things except to release. Maybe release-requirements.txt.
[17:34:05] <Ivo> jaraco.packaging.release doesn't seem to make a wheel by default atm if I'm reading correctly
[17:37:46] <jaraco> I just accepted your PR in github. It occurs to me the release process might choke when it gets to pushing the code to github.
[17:39:46] <Ivo> eh, it was like a one line change anyway, I guess you could force back out the github PR and apply it yourself in hg if you wanted?
[17:41:10] <Ivo> oooh, this is one thing I like about mercurial... to add a plugin, just pip install something
[17:42:14] <Ivo> so what do I want to `hg clone https://github.com/jaraco/setuptools github` or something?
[17:44:47] <jaraco> The way I have it is an hg clone of the bitbucket repo as ‘default’ and then an hg-git pull of the github repo.
[17:46:25] <jaraco> At this point, the “repeatable” process is feeling a little bit to me overcomplicated.
[17:52:45] <Ivo> unfortunately hg does not work nicely with hg extensions that were installed ina virtualenv instead of teh global env
[17:56:17] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[18:00:14] <Ivo> totes need make it check and go "I just checked. Are you lying to me? y/n" if you are
[18:03:10] <Ivo> ok I'm trying to push a single commit for .travis.yml which I thought was on default branch, and it's saying
[18:03:16] <Ivo> Just say that tests are passing. It doesn’t check. ote head de7ee4680b5b on branch '0.7-maintenance'!
[18:11:54] <jaraco> Often, you can ‘hg strip -r outgoing(default)’ and that will remove any commits not upstream.
[18:15:31] <Ivo> http://stackoverflow.com/questions/6927733/mercurial-how-to-deal-with-one-branch-that-has-two-heads
[18:15:55] <jaraco> Yes. or closed or something. I keep thinking something is going to happen with that code, but it’s kinda dragging on.
[18:25:04] <jaraco> Yes. But its advertised advantages don’t help me, and it adds another dependency and handoff.
[18:26:06] <Ivo> if you started off with an empty dist/ folder and then built some packages, you can just do twine -u dist/*
[18:26:24] <pmxbot> Ivo; brain the size of a planet....
Reduced to writing about encryption for mortals; gets very depressed.
[18:28:56] <jaraco> Not sure; I don’t get prompted for a password, but that’s because I store my password in .pypirc and have github and bitbucket passwords already stored elsewhere.
[18:35:39] <Ivo> jaraco: you should just make it prompt for a username, with a default if you press Enter
[19:06:53] <jaraco> I’m always online - just not always on IRC. You can often reach me on Twitter or Slack (python-developers and python-community).
[19:58:02] <jaraco> ronny: Any objections to me just pushing forward with the github migration for setuptools?
[20:37:22] <dstufft> jaraco: planning to keep it at github.com/jaraco/ or going to put at agithub.com/pypa ?
[20:42:07] <ronny> jaraco: the tool is unfinished, and due to fmily visit i didnt have time to finish the username mapping while burning the leftover vacaton before starting a new job
[20:42:09] <jaraco> Heya ronny. I’m fighting https://github.com/jeffwidman/bitbucket-issue-migration/issues/65 right now.
[20:42:55] <ronny> jaraco: because afair that one is seriously broken, and mine is bascially a complete rewrite
[20:43:26] <jaraco> That repo has undergone some major revisions, and is more stable now with an active maintainer.
[20:43:27] <ronny> jaraco: i finished the tooling around username mapping, but i havent finished the comment editing to actuallly replace username references
[20:43:45] <jaraco> But I’ll review your commits and incorporate any relevant fixes into the upstream before finalizing the migration.
[20:44:23] <ronny> jaraco: i did a complete rewrite/restructure (since it wasa good chance to re-calibrate my instincts
[20:44:53] <ronny> there is incremental download, offline transformation and a completely separate bulk upload step
[20:47:08] <jaraco> ronny: that’s cool. The latest upstream version uses an import API created for this purpose. But the offline transformation sounds helpful.
[20:47:43] <ronny> jaraco: i dodownload the bb issues, support incremental updates of the comments downloaded, and offline transform to bulk upload requests
[20:48:26] <ronny> the part thats missing in my code is using the username map that maps github users to bitbucket users to add the extra metadaa to the comments (loke original poster/reference to unknown bitbucket users=
[20:53:00] <jaraco> Sounds good. I linked this IRC discussion to the ticket for the migration. One of us or someone else can follow up based on the update.
[21:05:13] <jaraco> Thanks ronny. If you decide it’s too much work, it’s not a hard requirement - just looking to get the best fidelity we can during the migration with a modest amount of work.
[21:43:37] <tomprince> dstufft: https://github.com/warner/python-versioneer is a `setuptools-scm`-alike that generates sdists with backed in version.