Log file Viewer

[13:40:48] <doismellburning> I would like my project to depend on a git url

[13:41:16] <doismellburning> at least for development; is dependency_links the recommended method for this?

[13:47:22] <mgedmin> you can put git urls into requirements.txt

[13:48:22] <mgedmin> e.g. git+https://github.com/mgedmin/ghp-import@0be8353fdf427e1bd79e26a94d7a2d707382417e#egg=ghp_import-master

[13:48:54] <mgedmin> I think pip freeze gave me that, I'm pretty sure I wouldn't have come up with such syntax myself

[13:52:29] <doismellburning> mgedmin: alas that is not setup.py

[13:52:44] <mgedmin> no

[13:52:52] <mgedmin> you can do the same in install_requires, but I wouldn't

[13:52:57] <doismellburning> you can't

[13:53:03] <mgedmin> wait, really? oh

[13:53:05] <doismellburning> unless I've missed something

[13:53:11] <doismellburning> hence dependency_links tedium

[13:53:14] <mgedmin> you do nbeed the special #egg=Name

[13:53:20] <mgedmin> in the URL

[13:53:34] <mgedmin> or you can also use dependency_links

[13:53:55] <mgedmin> (but I wouldn't)

[13:54:57] <doismellburning> mgedmin: I disagree re the former

[13:55:18] <mgedmin> which one is 'the former'?

[13:55:56] <doismellburning> mgedmin: "you do need the special #egg=Name#"; that is insufficient

[13:57:08] <doismellburning> (re "or you can also"; that's not an "or", afaict)

[13:58:36] <mgedmin> I'll not argue -- my memory of the allowed syntax is imperfect

[13:59:11] <mgedmin> and I never linked to concrete locations of unreleased packages in my setup.py, for reasons that are hard to describe

[13:59:18] <mgedmin> ("it felt wrong")

[13:59:38] <mgedmin> I put links in requirements.txt or buildout.cfg's find-links = ...

[14:00:24] <doismellburning> I'm not entirely convinced that setup.py is really the right tool for "project" metadata (vs library)

[14:02:30] <mgedmin> my view: setup.py defines things for project users; requirements.txt (or buildout.,cfg) defines things for project developers

[15:14:21] <techtonik> hi #pypa. any windoze users here?

[15:18:12] <techtonik> for me the bug https://github.com/pypa/virtualenv/issues/649 is pretty critical, but nobody seems to care. did I broke something on my system?

[15:58:54] <techtonik> found a duplicate. seems like windows users:

[15:59:08] <techtonik> 1. don't use virtualenc

[15:59:33] <techtonik> 2. use only latest gitub version

[15:59:53] <techtonik> 3. use non-standard python distribution

[16:00:59] <techtonik> virtualenv (and tox) installable from pypi can not work correctly with python installer of python.org

[16:01:46] <techtonik> can anybody here backport the fix and release a new version? i definitely can't.

[16:53:37] <nanonyme> Anyone here happen to know the reasoning why the "py" script wasn't included on Linux?

[16:53:43] <nanonyme> Or am I just wrong and it is?

[16:59:10] <apollo13> techtonik: well from the ticket it looks like you'll have to wait for 0.12

[17:00:45] <pf_moore> techtonik: yes, wait for 12.0. It's a relatively rare situation where you have a user install of Python. I can't recall the details but AFAIK it doesn't affect most people (I suspect the majority use system level installs)

[17:01:32] <pf_moore> more specifically, regarding your point (3), I suspect most Windows users use a standard "All users" install.

[17:17:01] <nanonyme> Sounds likely

[17:17:12] <nanonyme> I don't think most users even pay attention to other options existing

[17:17:27] <nanonyme> *I* didn't know they did

[17:27:27] <doismellburning> 2

[17:28:34] <doismellburning> sorry

[17:34:13] <dstufft> The next release shouldn't be too far away

[18:24:15] <techtonik> nanonyme: because Linux processes shebangs and Windows doesn't do this - http://legacy.python.org/dev/peps/pep-0397/ - but I'd use py executable on Linux

[18:24:27] <techtonik> for consistency

[18:25:23] <techtonik> i constantly use `py -2` and `py -3` because something got wrong with default association

[18:27:46] <techtonik> pf_moore: That explains it. I patched my copy of virtualenv in the meanwhile.

[18:28:45] <techtonik> dstufft: thanks for the notice. now i can sleep well =)

[19:37:10] <nanonyme> techtonik, well, we could have #!/usr/bin/py -3 on Linux too

[19:37:35] <nanonyme> The python vs python2 vs python3 vs python2.x vs python3.x situation on Linux is pretty much horrible

[19:39:12] <nanonyme> You have no guaranteed way of getting a particular version of Python in a cross-distro way

[19:40:00] <dstufft> /usr/bin/py -3 on linux would make it far less likely to have broken shebangs

[19:40:13] <dstufft> mostly because the fact that shebangs with spaces don't work at all

[19:40:26] <dstufft> and the only way around that is some sort of wrapper script :/

[19:41:07] <nanonyme> Yes. So let's have py on Linux too

[19:45:02] <nanonyme> If the only way is to have a wrapper script, let's at least have a wrapper script with same semantics everywhere

[19:45:19] <techtonik> And py2 and py3 as helpers? )

[19:45:53] <techtonik> py.exe semantics is not good.

[19:46:31] <techtonik> On my system I want py to be python2 and python to be python3.

[19:46:45] <techtonik> Regardless of what is written in the script.

[19:47:15] <techtonik> And last time I tried to doit with py config, I failed.

[19:48:35] <techtonik> The problem with most PEPs that they don't contain all usage stories. They are written more like specification than a recipe book.

[19:48:58] <techtonik> And it is hard to tell if your particular story is there.