Log file Viewer

[01:04:54] <FunkyBob> I've a question about setup.cfg ... how do I express my install_requires list, and in which section does it go?

[01:25:47] <toad_polo> FunkyBob: In `options `, I think it can be a comma separated list or newline delimited

[01:28:13] <FunkyBob> toad_polo: thanks... yeah, I guessed newlines would work... and they did

[01:28:29] <toad_polo> 👍

[01:28:36] <FunkyBob> I'm generally moving over to "empty setup.py" pattern these days

[01:28:44] <FunkyBob> [not exactly empty, but you know what I mean...]

[01:30:02] <toad_polo> I dig it. I was just adding support for literally missing setup.py the other day.

[01:30:55] <toad_polo> Not landed yet because it's blocked on another more important change that would conflict, but we'll get there.

[01:33:28] <njs> with the latest pip it's even possible to skip setup.py entirely, and use alternative build systems. Like flit, which is entirely declarative. (Doesn't support extension modules though.)

[01:33:29] <FunkyBob> so I can get away with just setup.cfg and no setup.py ?

[01:33:39] <FunkyBob> njs: interesting

[01:34:26] <toad_polo> Soon you will be able to, yes.

[01:34:54] <toad_polo> Flit does not use setup.cfg, but also doesn't use setup.py

[01:37:51] <FunkyBob> ah, it uses pyproject.toml

[01:38:29] <njs> all problems in computer science can be solved by adding another layer of indirection

[01:38:33] <njs> pyproject.toml is our new layer of indirection :-)

[01:38:41] <FunkyBob> :P

[01:39:52] <toad_polo> Also no src layout, last I heard. 😭

[01:44:37] <njs> src/ layout is so annoying :-(

[01:45:05] <njs> I get why people do it, but I can't help thinking that the right solution is to fix the issues with package-in-root as opposed to making everyone move to the more annoing layout

[01:45:17] <toad_polo> Annoyingly great.

[01:46:42] <toad_polo> The problems with package-in-root are inherent in the way the path is configured with Python, I don't see a way to fix it any more than we can fix the GIL.

[01:47:23] <toad_polo> Plus aesthetically I do like the symmetry of it.

[01:48:20] <njs> the main issue I know of is accidentally testing the wrong thing. but this is totally fixable by testing tools.

[01:49:32] <toad_polo> There are other issues.

[01:50:57] <toad_polo> `find_packages `, various other non-testing related issues from importing the non-installed version.

[01:51:44] <toad_polo> Anyway, no one's forcing you to use it, just because not using it is morally wrong. 😛

[01:53:47] <njs> I suspect there's a hidden conflict between people with different workflows that are more-or-less impacted by this

[01:54:32] <njs> possibly, those using IDEs with some java heritage that assume you have an awful directory layout and compensate for it, versus everyone else

[01:58:07] <FunkyBob> how is it a more annoying layout?

[01:58:35] <FunkyBob> I've recently switched to using src/ ... it's a tiny impact on my workflow, and makes setup.py/cfg far easier to get right

[02:21:19] <njs> I interact with sources from the command line a lot, and typing src/ all the time is pretty annoying. Also, I like to test directly against the source tree when developing locally, because for quick tests between edits, simplicity and speed trump all

[02:22:07] <njs> (and I can't do rigorous testing locally anyway, that's what CI is for.)

[02:25:41] <FunkyBob> when developing locally I just "pip install -e ." and it all "just works"

[02:27:03] <FunkyBob> am trying to remember which one of my friends I saw do a post on why they moved to using src/

[03:04:33] <FunkyBob> toad_polo: any tips on defining entry points?

[03:04:40] <FunkyBob> ValueError: Entry points must be listed in groups

[03:08:32] <FunkyBob> or, a definition of the setup.cfg syntax :/

[03:11:49] <energizer> https://hynek.me/articles/testing-packaging/ and bit.ly/pypackaging discuss the advantages of src/. testing against the source tree is done by installing the source tree `-e .`. without source, you may be testing a different version than you're distributing

[03:12:55] <energizer> i'm not sure how often i actually type "src/" ?

[03:13:28] <energizer> generally i'm using `python -m ` or setuptools console_scripts anyway

[03:14:05] <energizer> i cant immediately think of any exceptions, are there some?

[03:18:19] <FunkyBob> gah... I'd fixed my config, but the egg files were confusing things

[03:34:28] <njs> energizer: 'less mypkg/somefile.py' :-)

[03:36:17] <njs> I also generally don't bother to set up separate virtualenvs for every project or develop installs, that's a ton of complexity and moving parts and I don't miss them

[03:38:59] <tdsmith> i don't think i've ever had a moment where i thought "ah, this is where src/ would have saved me"

[03:40:23] <tdsmith> i understand that other people have strong convictions about these circumstances and their importance

[03:42:38] <energizer> njs: not sure what you mean about complexity: `virtualenv venv && venv/bin/pip install -e .` ?

[04:02:22] <njs> energizer: venvs have a lot of moving parts. the simple case is simple, but there's a lot of scope for things to go wrong. e.g. inevitably when I switch to a new project dir, the venv will have been broken by a system upgrade or something...

[10:52:34] <toad_polo> There's your problem, using the system install for anything is a mistake.

[10:52:43] <toad_polo> That's the system's Python.

[12:05:55] <dstufft> njs: example: In cryptography it was literally impossible to not have a src/ directory, and _not_ import from the local directory during testing instead of testing the installed artifact

[12:06:12] <dstufft> njs: I suspect the answer is the same for ~100% of people who don't bundle their tests as part of the installed library

[12:08:02] <dstufft> njs: and the reason why should be pretty obvious ;) If you need to put $ROOT on the sys.path in order to import from $ROOT/tests, then you're also going to end up importing from $ROOT/mylib

[12:13:58] <njs> dstufft: <njs> I get why people do it, but I can't help thinking that the right solution is to fix the issues with package-in-root as opposed to making everyone move to the more annoing layout

[12:14:21] <dstufft> njs: how do you fix the issue of I want to import one item from this directory but not another?

[12:14:23] <njs> dstufft: also this discussion finally prodded me into filing this: https://github.com/pytest-dev/pytest/issues/4714

[12:14:36] <dstufft> like, that's sort of just how the Python import system works

[12:14:38] <njs> annoyance-driven-development

[12:14:40] <njs> not so!

[12:14:52] <njs> click the link and be introduced to the wonder of sys.meta_path

[12:15:25] <njs> (but yes, this is actually one of the major reasons I end up doing tests-in-library)

[12:17:47] <dstufft> er sorry, was about to say without sys.meta_path hacks, but I suspect those cause more pain than they offer in help here. You have to know up front which directory your tests are in to add them to the metapath thing, which means py.test . would break I think

[12:18:12] <njs> dstufft: pytest always knows where the tests its trying to import are

[12:18:17] <njs> dstufft: that's how it knows to import them

[12:18:31] <dstufft> njs: only after it's imported everything I think in order to discover them?

[12:18:46] <njs> it discovers them by walking the filesystem tho

[12:18:51] <dstufft> note I just woke up a bit ago, so I could be remembering how pytest's importer works

[12:18:57] <njs> you can't like 'import *.*' in python :-)

[12:21:28] <dstufft> sure you can

[12:21:39] <njs> dstufft: ?

[12:22:08] <njs> how do I import 'tests/test_foo.py' without first looking in the directory and discovering that there's a test_foo.py file there?

[12:22:29] <njs> assume that tests/__init__.py is empty

[12:23:39] <dstufft> map(importlib.import_module, [mod.name for mod in pkgutil.walk_packages()])

[12:27:53] <njs> heh. pkgutil.walk_packages() is an interesting hybrid of importing and filesystem walking! I don't think pytest uses it though.

[15:56:30] <adder> hi, I'm looking at https://docs.travis-ci.com/user/deployment/pypi/, how does Travis know when to upload to PyPI? Does it automatically upload on *every* tagged commit? Or is there some way to specify that some tag, like "go travis" for instance triggers it?

[15:58:28] <ngoldbaum> if you have "on: tag" it does it only for tagged commits yeah

[15:58:50] <ngoldbaum> adder: https://docs.travis-ci.com/user/deployment#conditional-releases-with-on

[16:00:54] <adder> ngoldbaum: PyPI page says 'on: tags: true'

[16:01:07] <ngoldbaum> right, that's what i meant

[16:01:18] <ngoldbaum> did you look at that link i shared?

[16:02:16] <adder> ngoldbaum: yes I did

[16:03:22] <ngoldbaum> ok, hope that answers your question

[16:03:55] <adder> it does I guess, thanks :)

[23:24:00] <toad_polo> I don't think pytest imports the tests in the traditional way. Most test folders aren't modules. Pytest itself doesn't add the package root to the path, though.

[23:47:35] <ScottK> Using setup.cfg to list the files to be installed, is there a way to install files from the top level of the package (e.g. README or LICENSE) without having to use MANIFEST.in?

[23:54:58] <toad_polo> License yes, license_file=LICENSE will handle that for you.

[23:55:25] <toad_polo> Readme I think needs to be in the manifest I think.