Log file Viewer

[13:32:04] <MrJones> I have a problem installing a package of mine. this is the MANIFEST.in: http://fpaste.org/302715/14504448/raw/ this is a "tree" output of the project dir followed by the first output of running "python setup.py install": http://fpaste.org/302714/14504448/

[13:32:10] <MrJones> as you can see, it gives warnings about none of the MANIFEST.in patterns matching anything at all. however, if you check the tree above it clearly should have matched things. is there any obvious mistake I made?

[13:32:48] <ionelmc> MrJones: how do you run setup.py?

[13:33:01] <ionelmc> pastebin complete terminal session

[13:33:19] <mgedmin> MANIFEST.in has nothing to do with setup.py install

[13:33:24] <mgedmin> MANIFEST.in is used by setup.py sdist

[13:34:13] <ionelmc> mgedmin: unless include_package_data=True is used

[13:34:13] <mgedmin> (although setup.py install runs setup.py egg_info under the hood, which uses MANIFEST.in to create SOURCES.txt)

[13:34:23] <MrJones> ionelmc: which I do indeed use

[13:34:34] <MrJones> and the data that was supposed to be included is now missing :-/

[13:34:45] <ionelmc> just pastebin more stuff

[13:34:49] <ionelmc> setup.py contents

[13:34:54] <ionelmc> cwd and command line

[13:35:39] <mgedmin> "/tmp/daphnesetup-986f5b01-a012-48a0-999e-fc1fbd332d95"

[13:35:46] <mgedmin> is that a temporary virtualenv or something?

[13:35:49] <MrJones> yea

[13:36:52] <mgedmin> distutils is picky about trailing slashes in directory names, but I don't remember if it wants them or hates them

[13:36:59] <MrJones> setup.py contents: http://fpaste.org/302718/14504454/raw/

[13:37:36] <mgedmin> all MANIFESTs I use have recursive-include sub/dir *.foo without a trailing slash after sub/dir

[13:38:09] <mgedmin> but maybe that's unrelated -- I now remembered that IIRC I only saw problems from trailing slashes when I tested on Windows

[13:38:21] <MrJones> mgedmin: that solved it :/

[13:38:23] <MrJones> I'm on linux

[13:38:28] <mgedmin> oh, cool

[13:38:33] <MrJones> that's quite an awful quirk... maybe wanna fix that??? lol

[13:38:34] <mgedmin> maybe I'm misremembering

[13:38:52] <ionelmc> tbh i find the idea of using recursive-include to be quite silly

[13:39:06] <MrJones> well so is requiring no slash at the end :p

[13:39:18] <ionelmc> unless you often have jukn in your source tree a graft is most always easier to use

[13:39:23] <mgedmin> MrJones, want to file a bug?

[13:39:47] <mgedmin> oooh graft vs recursive-include? let's fight!

[13:40:06] <mgedmin> (only I have no time for an irc fight, and also I've never used graft so I've no idea what it does, exactly)

[13:40:20] <mgedmin> anyway, I prefer to include only things I ask for, instead of including everything by default

[13:40:28] <mgedmin> my source trees often contain junk (vim swap files etc.)

[13:40:41] <mgedmin> and I trust check-manifest to remind me when I forget to add something to manifest.in

[13:41:38] <ronny> hi

[13:46:06] <ionelmc> mgedmin: same argument for graft

[13:46:13] <ionelmc> check-manifest

[13:46:20] <ionelmc> but less manifest.in churn

[13:47:18] <MrJones> mgedmin: thanks for the hint anyway :) now it works

[13:49:11] <timous> hello

[13:59:20] <timous> I met the issue about pip uninstall which succeeds but ends with an error (https://github.com/pypa/pip/issues/3045)

[13:59:43] <timous> I don't understand where it comes from

[14:00:42] <timous> Is it a pure pip issue or the combination of a bad setup.py and a pip subtility?

[16:01:51] <rando305> Just for clarification, does pip install 'app'

[16:02:48] <rando305> does pip install 'app' --upgrade take you to the latest release of the code, or the latest master version of the code. I assume it is the latest release. If I want to get the latest version of the master, can I do that with pip install?

[16:29:28] <hashar> rando305: pip installs from pypi so it would be whatever latest version has been published there

[16:29:35] <hashar> rando305: else you will want to install from the SCM repo

[16:30:17] <hashar> something like: pip install 'git+https://example.org/author/repo.git@master#egg=packagename'

[17:03:12] <ronny> hi jaraco

[17:03:22] <jaraco> Hello ronny

[17:05:42] <ronny> jaraco: would it be acceptable to have a git repo for the username mappings of github<>bitbucket for the pypa projects?

[17:07:53] <jaraco> ronny: Do you mean all of the tickets/comments would be migrated under a single user, but people could look up the github username in the repo by hand if they wanted?

[17:08:57] <ronny> jaraco: yes, there would be correct references to github user if possible and link to bitbucket user if not

[17:09:42] <ronny> jaraco: oh btw, can i get admin for setuptools_scm - i#d like o set up appevoyer

[17:10:59] <jaraco> You should have admin to setuptools_scm.

[17:11:06] <jaraco> (already)

[17:12:08] <ronny> jaraco: i recall having it on the first repo, but then you fixed the my blunter with the issues - ut perhaps appevoyer is just acting up cause i dont have enough perms in the organisation

[17:13:13] <ronny> jaraco: btw, any oppinion on a disable_easy_install flag that would disable the normal install commands and leave only bdist_wheel, develop and sdist intact ?

[17:14:19] <ronny> (would come into the setup call)

[17:15:56] <jaraco> ronny: sounds like a change that would be unacceptable - if a package could elect to be uninstallable via setuptools, some packages would elect that right away, and packages that depended on that using setuptools would break.

[17:16:31] <jaraco> It would break the ecosystem. It’d be almost as easy to just remove all installer capability from setuptools altogether.

[17:18:44] <ronny> jaraco: novody distributes as eggs anyway, - and most of the things i see that are still on eggs just stay there because they are let to live (buidlout, strange plugin systems, setup_requires)

[17:18:53] <ronny> *nobody

[17:19:29] <ronny> jaraco: and even when i tried to make eggs, i turned out to bee acomplete pain since they require pyc files and cant be source only zipfiles

[17:22:02] <jaraco> It’s a shame that wheels were forked from eggs. I’d like to see those two forms unified again. They’re mostly the same. Just need to make sure that wheels can be installed in an encapsulated manner (don’t require to be installed in an environment to be usable), and add support for installing wheels in setuptools, then eggs can be deprecated in favor of wheels.

[17:23:37] <jaraco> Regarding setup_requires, that’s a really powerful feature, despite its shortcomings… allowing a single command to run a full suite of tests with minimal prior setup.

[17:23:52] <jaraco> I’d want there to be a replacement for that before eliminating setup_requires.

[17:25:49] <jaraco> But anything that removes functionality should have a good story on how to migrate to something better, or at least a really clear reason why no one should every do that. You can’t simply deprecate an entire ecosystem like buildout without creating a compelling alternative.

[17:28:45] <ronny> jaraco: well, both eggs and wheels are both broken in different ways

[17:29:44] <ronny> jaraco_: i have a rough idea for correct multi version incapsulated installs that can be shared among virtualens even, but i doubt i#ll have the engineering tome to implement it

[17:30:26] <ronny> (let alone specing it out)

[23:05:25] <horatiohb> I'm trying to get pip to print a list of all versions of an upstream, uninstalled package. I tried "pip install -v --no-install ..." but pip didn't recognize the --no-install flag. Anyone know what's going on?