pmxbot IRC Log Viewer

[11:39:34] <frederfred> If maintaining a private repo, is the only "safe" way of falling back to PyPI when installing packages to use a proxying private repo?

[11:40:40] <frederfred> For instance if creating packages for ACME corp. and uploading them to a private repo using the namespace acme (acme.foopkg etc.).

[11:44:43] <frederfred> AIUI, if using --extra-index-url, there's the possibility that someone could create a dist. on PyPI with the same name as an internal dist. and a higher version, which would be then chosen in preference to the "real" company-internal dist. And it seems there's no way to register an organisational namespace on PyPI - even if ACME uploads acme.foopkg, someone else could upload acme.barpkg tomorrow, correct?

[11:57:43] <pradyunsg> frederfred: FYI -- a discussion on namespacing on PyPI -- https://discuss.python.org/t/namespace-support-in-pypi/1609/35

[11:59:01] <frederfred> pradyunsg yeah I'm already reading my way through that haha

[11:59:23] <pradyunsg> frederfred: i linked to a comment that's a pretty good summary.

[12:01:51] <frederfred> Yeah, so much as I surmised then!

[12:02:12] <frederfred> So are there any "safe" alternatives to a proxying repo?

[12:02:58] <frederfred> E.g. pip alternatives that allow for switches/config. for how to select between multiple packages with the same name from different repos?

[12:03:04] <pradyunsg> frederfred: I don't know if devpi/any-other-OSS-python-index-proxy tool has support for conditional fallbacks and what the current recommendation should/would be -- consider poking that thread to ask if anyone came around to point 3 from that summary.

[12:03:11] <frederfred> (Which the proxying private repo is just a hack for really)

[12:03:24] <frederfred> Might do that, thanks :)

[12:04:36] <frederfred> Or having a "signed by" param for specific packages.

[14:22:23] <pyusr> hmm... how bad is it to do something like:

[14:22:48] <pyusr> setup.py: setup(setup_requires=['Cython'], install_requires=['Cython']) and once setup(ext_modules=cythonize("source/*.pyx", compiler_directives={'language_level' : "3"})) ?

[14:22:54] <pyusr> to get cython pre-installed ?

[14:23:16] <toad_polo> pyusr: Just use PEP 518

[14:24:20] <pyusr> can I use [build-system] in setup.cfg ?

[14:25:42] <pyusr> seems no... so I need yet another file :/... I already have setup.py so I rather not have another file, is doing that bad (it works)

[14:27:03] <toad_polo> Yes you need that file.

[14:27:29] <toad_polo> It's not a configuration for setuptools, it's a configuration file for other tools that invoke setuptools.

[14:27:54] <toad_polo> At some point in the future we will add support for putting anything that could go in setup.cfg into pyproject.toml

[14:29:04] <toad_polo> But I dunno what the big deal is with multiple files that do different things.

[14:30:58] <toad_polo> And to be clear, if you use `setup_requires` *without* a PEP 518 build, it might invoke easy_install, which is a very bad idea.

[14:32:28] <pyusr> the thing is that it's too confusing to do sane packing in python :/

[14:35:06] <pyusr> I've written a cython based package, now I'm trying to figure the best way to package it, and to make it pass coverage pytests ...

[14:35:09] <pyusr> any tips ?

[14:36:37] <nedbat> pyusr: what happened to using tox?

[14:38:18] <pyusr> it complaint about not having cython as a dependency and I got side-tracked into figuring what's the best way to fix that..

[14:45:58] <pyusr> toad_polo: https://github.com/statsmodels/statsmodels/blob/master/pyproject.toml I did something like that but pip install -e . doesn't install cython ?

[14:49:48] <pyusr> the amazing stuff is that stackoverflow is filled with questions on how to get cython as a dependency for installation (with no real help)

[14:50:33] <pyusr> ohh, hmm.. my venv had an old setuptools / pip, trying again

[14:51:15] <pyusr> nop

[14:55:40] <toad_polo> I think you should still add `build-backend="setuptools.build_meta"`, but that should work.

[14:57:49] <toad_polo> I just created a test project and `pip install .` and `pip install -e .` both work when Cython is included in the build requirements.

[14:58:00] <toad_polo> If I remove it from the build requirements both fail.

[14:58:56] <pyusr> all I have to do is put pyproject.toml in my main dir with [build-system] requires=["cython"] ?

[14:59:32] <toad_polo> No you also need `"setuptools"` and `"wheel"`.

[15:00:41] <pyusr> yeah, tried that as well :/ i'll try a demo one like you did and see if it works!

[15:01:31] <toad_polo> Is your project on github or something/

[15:02:06] <pyusr> the cython based version not yet, I'll upload it, sec

[15:04:27] <pyusr> https://github.com/tzickel/chunkedbuffer/tree/blah

[15:05:02] <pyusr> (don't try to run it or follow the README.md examples, I haven't finished working on them, as I'm trying to get the packaging and coverage testing to work now)

[15:05:28] <gnomeza> pyusr: virtualenv will (sometimes?) install (old) hardcoded pip and setuptools versions. Update virtualenv first.

[15:05:41] <pyusr> gnomeza: yeah I figured that and did it

[15:06:04] <gnomeza> There was also a virtualenv option to prevent that, was it --no-download?

[15:06:35] <gnomeza> pip within virtualenv must be >18 for it to pick up pyproject.toml, iirc

[15:07:06] <toad_polo> pyusr: How is it failing for you?

[15:07:06] <pyusr> i'm on 20 now

[15:08:35] <pyusr> hmm... ok, I am confused, but you are correct, it works, I just didn't notice between all my experiments :/

[15:08:42] <toad_polo> That works fine for me.

[15:08:48] <pyusr> I was just expecting cython to exist in my venv afterwards

[15:08:59] <toad_polo> No, it does't.

[15:09:04] <toad_polo> It's a build-time dependency.

[15:09:42] <toad_polo> That's the point of PEP 518, it creates a temporary build environment with all your build time dependencies in it.

[15:10:11] <ngoldbaum> if you need cython at runtime you can declare it as a runtime dep though

[15:10:19] <toad_polo> They're isolated as well, so stuff you have installed in your virtualenv or your standard python environment won't be present.

[15:12:45] <pyusr> cool, I'll try it

[15:13:04] <pyusr> now I'll get back to figuring pycoverage with cython in CI/CD

[15:28:28] <pyusr> toad_polo: how can I get tox to see that pyproject.toml ?

[15:28:43] <pyusr> it fails on not finding Cython on sdist-make

[15:34:46] <pyusr> guess, I can add it as a manual dependency

[15:39:10] <pyusr> toad_polo: can you check that project again, and see how to get "tox" working ? it complaints about not finding my module

[15:40:03] <pyusr> i get E ModuleNotFoundError: No module named 'chunkedbuffer'

[15:53:51] <toad_polo> pyusr: I think you need to set isolated_build = True or something.

[15:54:55] <toad_polo> https://github.com/pganssle/zoneinfo/blob/9829972933553906f710c36c40231a38ccd20e53/tox.ini#L3

[15:57:17] <pyusr> will try

[15:58:58] <pyusr> that gives me on running tox: ERROR: missing build-backend key at build-system section inside /home/user/Desktop/chunkedbuffer/pyproject.toml

[16:02:35] <pyusr> yey, fixed that, now I get: ValueError: 'chunkedbuffer/*.pyx' doesn't match any files

[16:37:03] <pyusr> any idea how to make it "see" the pyx files ?

[16:45:57] <ngoldbaum> what is “it”

[16:46:26] <ngoldbaum> it helps instead of just sharing the error that gets raised to instead pastebin the full output you’re seeing in your terminal

[16:46:44] <dude-x> ngoldbaum you've triggered "epic" in my head.

[16:47:06] <ngoldbaum> dude-x: ? “epic”

[16:47:20] <dude-x> ngoldbaum don't look it up now. it's a song.

[16:48:23] <pyusr> ngoldbaum: https://bpaste.net/VTQQ

[16:49:36] <ngoldbaum> what does your setup.py look like?

[16:50:21] <ngoldbaum> those files exist?

[16:51:57] <ngoldbaum> if i were in your shoes i’d look around the place in the cython codebase where that error is getting raised to try and understand what’s up

[16:52:36] <ngoldbaum> usually if a build fails in the tox virtualenv it means something is fucky with the way you’re installing the package

[16:52:51] <ngoldbaum> is the cython code in MANIFEST.in, for examole?

[16:53:17] <ngoldbaum> tix is great for ferreting out packaging bugs you don’t notice if most of the time you work from a clone of a repo

[16:53:27] <ngoldbaum> s/tix/tox i hate phone keyboards

[16:55:27] <pyusr> ngoldbaum: yes pip install -e . works perfrectly outside of tox https://github.com/tzickel/chunkedbuffer/tree/blah

[16:56:49] <pyusr> pushed now the latest revision

[16:57:10] <pyusr> I'll check MANIFEST.in

[16:59:29] <pyusr> ngoldbaum: thanks ! one more step

[16:59:43] <pyusr> now I'll see how to enable that line tracing

[17:50:59] <pyusr> hmm... can anybody tell me what I've missing on why tox isn't showing me the .pyx files ?

[17:51:36] <pyusr> the dir /home/user/Desktop/chunkedbuffer/.tox/py36/lib/python3.6/site-packages/chunkedbuffer has only the *.so files not the .pyx is that the issue ? if so how to fix it ?

[17:53:48] <pyusr> (the source is updated in the link above)

[18:03:13] <pyusr> welp, found a solution, if I change the coverage test to use_develop and change --cov dir, it works :/

[18:05:28] <pyusr> toad_polo: I would agree, but unless you have a good idea on how to make that URL I linked work, it's the best option I've got

[18:05:49] <pyusr> I think the issue is that the .pyx files aren't copied to the virtualenv dir

[18:06:40] <toad_polo> One of the bigger problems is that you won't be testing "as installed", even if you switched to a src/ directory: https://blog.ganssle.io/articles/2019/08/test-as-installed.html

[18:07:14] <toad_polo> If you follow all that advice in the blog post and use `usedevelop`, because of the way `usedevelop` works, you get all the same problems.

[18:08:05] <pyusr> toad_polo: I would agree, but since I find 0 coherent documentation on how to properly do stuff like this, I don't know what to do / say

[18:08:24] <toad_polo> I spent a huge amount of time setting this up for a C project and I have not had time to write it up.

[18:08:31] <pyusr> I agree it's stupid and mad and annoying to search in github for repo that have cython and coverage support, and try random stuff

[18:08:33] <toad_polo> What is doing the code coverage? Just coverage?

[18:08:39] <pyusr> yes

[18:08:49] <pyusr> check the tox.ini and setup.cfg files in that repo

[18:08:54] <pyusr> (the blah branch)

[18:09:31] <toad_polo> I more or less got C coverage to work with a little hack in the `setup.py`.

[18:09:43] <toad_polo> https://github.com/pganssle/zoneinfo/blob/master/setup.py#L12-L40

[18:11:32] <toad_polo> That was a limitation of `gcov`, though. I end up running it in a separate job becauase it's such a hack :(

[18:13:51] <pyusr> my main goal now, is to get my library working and test, not to hack on packaging :)

[18:13:55] <toad_polo> I dunno if it's really worth pulling your hair out, but it's probably worth raising an issue somewhere.

[18:14:50] <toad_polo> Not sure where, though. I think this might be a good start: https://github.com/pypa/packaging-problems

[18:15:42] <pyusr> thats for tox stuff as well ?

[18:16:47] <pyusr> heh, on that blog you linked, there is an article related to the library I'm working on: https://blog.ganssle.io/articles/2019/11/string-concat.html

[18:16:52] <toad_polo> Or alternatively: https://discuss.python.org/c/packaging/14

[18:18:40] <pyusr> thanks for all the help getting me back to atleast able to write testing for my code !

[18:27:08] <toad_polo> pyusr: Yeah, the tox maintainers will see it if you put it either of those places.

[18:27:20] <toad_polo> It's not a tox problem at its core, though.

[18:28:19] <toad_polo> pyusr: In what sense?

[18:28:57] <toad_polo> I mean I can see that they both have to do with allocations and such.

[18:43:18] <ngoldbaum> overwhelming likelihood you’re not doing the packaging correctly

[18:44:03] <ngoldbaum> tox failing is a symptom of that

[18:56:45] <pyusr> ngoldbaum: I'm open for feedback, th ecode is there...

[18:57:06] <pyusr> toad_polo: data copy optimizations

[18:57:09] <ngoldbaum> where?

[18:57:37] <pyusr> https://github.com/tzickel/chunkedbuffer/tree/blah (this is branch blah)

[18:58:52] <ngoldbaum> you need a thing in your call to setup() so the .pyx files actually get installed from the tarball

[18:59:31] <ngoldbaum> https://setuptools.readthedocs.io/en/latest/setuptools.html#using-find-packages is what most projects want

[19:00:20] <toad_polo> ngoldbaum: It's pretty unusual to install pyx files.

[19:00:39] <ngoldbaum> not in my experience

[19:00:49] <ngoldbaum> shipping generated C is a bad idea IMO

[19:01:22] <toad_polo> You ship the pyx files but you install .so files.

[19:01:44] <ngoldbaum> ok maybe i’m not diagnosing this correctly

[19:02:37] <ngoldbaum> it seems that in pyusr’s case something isn’t moving the pyx files into the build environment

[19:02:57] <ngoldbaum> in the past when I’d had similar problems the solution was to install the pyx files

[19:03:01] <ngoldbaum> what shoild

[19:03:10] <ngoldbaum> should i have done toad_polo?

[19:03:12] <pyusr> ngoldbaum: and how do I do this find_packages magic in setup.cfg ?

[19:03:23] <ngoldbaum> no idea

[19:03:34] <pyusr> k

[19:03:36] <ngoldbaum> i think it needs to happen at runtime in setup.py?

[19:03:41] <toad_polo> It's a directive.

[19:04:07] <toad_polo> https://setuptools.readthedocs.io/en/latest/setuptools.html#configuring-setup-using-setup-cfg-files

[19:04:24] <toad_polo> See where it says "find:", the options specified in `[options.packages.find]`

[19:05:59] <pyusr> ahh, k

[19:06:05] <toad_polo> Oh ngoldbaum you are right though, he's shipping the generated C not the pyx.

[19:06:09] <toad_polo> They rather.

[19:06:39] <toad_polo> I think you don't even need to call the cythonize method actually.

[19:07:41] <toad_polo> Maybe you do.

[19:08:26] <ngoldbaum> cython does want you to use the cythonize script like that, you don’t need to but it makes a lot of things way nicer

[19:08:38] <ngoldbaum> and is how e.g. incremental compilation works too

[19:09:12] <ngoldbaum> i think setuptools did grow built-in support for cython extensions at some point though

[19:09:27] <toad_polo> Here's a MANIFEST.in that you can crib from: https://github.com/pyminimp3/pyminimp3/blob/master/MANIFEST.in

[19:09:29] <ngoldbaum> the cython docs don’t use setuptools at all, all the examples only use distutils

[19:09:36] <ngoldbaum> which isn’t all that helpful these days

[19:09:45] <toad_polo> ngoldbaum: Yeah, I think setuptools grew that support pre-PEP 518.

[19:10:14] <toad_polo> To make it easier to avoid having to specify that Cython was available prior to `setup_requires` being executed.

[19:10:18] <pyusr> [options.packages.find]where = chunkedbufferinclude = *.pyx

[19:10:19] <toad_polo> With PEP 518 you can just import Cython in setup.py no problems.

[19:10:21] <pyusr> did nothing.....

[19:11:05] <pyusr> my MANIFEST.in has already recursive-include chunkedbuffer *.pxd *.pyx which does not help as well

[19:12:05] <ngoldbaum> MANIFEST.in determines what ends up in the tarball

[19:12:20] <ngoldbaum> you need to do more to install from the tarball correctly

[19:13:08] <ngoldbaum> you can debug all this yourself manually by making your own sdist and installing your package from the sdist manually

[19:13:22] <ngoldbaum> that might be less opaque than what tox is doing with virtualenvs

[19:13:32] <ngoldbaum> it’ll fail in the same way

[19:14:20] <ngoldbaum> i think if you do “pip install .” it’d fail the same way too, no sdist needed

[19:14:56] <pyusr> find_packages(".", include=["*.pyx"]) does not seem ok

[19:15:02] <pyusr> ohh, nm

[19:15:14] <toad_polo> I don't think you want that.

[19:15:50] <toad_polo> I mean, maybe you want it in some alternate version build that requires debugging, but I'm not sure what the point of actually including them in the package is.

[19:15:52] <toad_polo> They just need to go in the sdist.

[19:17:01] <ngoldbaum> toad_polo: because it seems like the pep 518 build never gets them copied over from the tarball

[19:17:13] <ngoldbaum> so they aren’t present at build time

[19:17:21] <toad_polo> ngoldbaum: Why would it?

[19:17:39] <ngoldbaum> so they can be compiled into an .so?

[19:17:46] <pyusr> ngoldbaum: setup(packages=find_packages("chunkedbuffer", include=["*.pyx"]), ext_modules=cythonize("chunkedbuffer/*.pyx", language_level=3, force=True, compiler_directives={'linetrace': True})) or am I doing it wrong ?

[19:17:49] <ngoldbaum> i’m not sure i understand

[19:18:06] <toad_polo> As long as they go in the tarball it's fine.

[19:18:08] <ngoldbaum> i think you just need find_packages with no args?

[19:18:21] <ngoldbaum> ok well pyusr isn’t seeing that apparently

[19:19:46] <toad_polo> I have no idea what is happening here. When I run `pep517.build -s .` on this, it's generating a tarball that includes random stuff.

[19:19:50] <pyusr> setup(packages=find_packages(), ext_modules=cythonize("chunkedbuffer/*.pyx", language_level=3, force=True, compiler_directives={'linetrace': True})) ofcourse no go as well

[19:20:20] <pyusr> ngoldbaum: would be nice to show me a repo where you have this, or tell me exactly what to do instead of me keep guessing this

[19:20:38] <ngoldbaum> i don’t

[19:20:56] <ngoldbaum> never tried to do exactly what you’re doing

[19:21:11] <pyusr> should i touch package_dir ?

[19:21:35] <ngoldbaum> i don’t know what that is

[19:21:47] <toad_polo> You don't need to use `find_packages` at all.

[19:22:29] <toad_polo> pyusr: Set your MANIFEST.in like this: https://bpaste.net/WULA

[19:22:31] <toad_polo> Or some variation of that.

[19:23:48] <pyusr> toad_polo: did you see my MANIFEST.in in the repo ? what's wrong with it ?

[19:24:29] <pyusr> ohh, sorry it's not commied, but it's one line: recursive-include chunkedbuffer *.pxd *.pyx

[19:24:37] <pyusr> I don't see the .pyx files inside the virtualenv dir

[19:24:37] <toad_polo> pyusr: When I pulled your repo there was no MANIFEST.in in it.

[19:24:49] <pyusr> yes, I forgot to git add it, but it's there

[19:25:42] <pyusr> I've pushed what I'm using now (tox with usedevelop=True)

[19:25:52] <toad_polo> Hm.. this is super weird.

[19:26:23] <pyusr> btw, I've copied it from a big project (the usedevelp to get coverage working): https://github.com/statsmodels/statsmodels/blob/master/tox.ini

[19:27:36] <toad_polo> Interestingly this works fine when I pip install it.

[19:28:13] <pyusr> when you pip install, where do you run the coverage from ?

[19:29:05] <pyusr> ohh, I'm doing pip install -e .

[19:30:53] <toad_polo> I'm not running coverage.

[19:32:25] <toad_polo> What's weird is that tox fials to build the wheel.

[19:33:46] <pyusr> maybe because the .pyx files aren't copied ?

[19:35:44] <toad_polo> Well I can see that they're copied into the sdist.

[19:36:12] <toad_polo> Ah, here we go, pip is failing to install from the sdist.

[19:37:37] <toad_polo> Ah wait, you have *.pxd files.

[19:37:37] <toad_polo> I see.

[19:40:08] <pyusr> yep, I put them in MANIFEST.in as well

[19:40:22] <toad_polo> pyusr: This should be better: https://bpaste.net/IE3Q

[19:41:01] <pyusr> toad_polo: isn't my MANIFEST.in enough ?

[19:41:19] <pyusr> or is the "include pyproject.toml" the issue ?

[19:41:30] <pyusr> (me missing it)

[19:42:23] <toad_polo> pyusr: Yes, yours is not enough.

[19:42:24] <pyusr> hmm, ok, I think that line fixe dthe sdist building

[19:42:32] <toad_polo> You need the pyproject.toml, and I would also include the .py files.

[19:42:49] <pyusr> ohh, the __init__ yes, thanks

[19:42:50] <pyusr> sec

[19:43:21] <toad_polo> The other stuff is also useful. Depending on what class of errors you want to protect against, switching to a `src/` layout and explicitly doing the recursive-include for the src/ and tests/ directories would probably be safest.

[19:43:59] <pyusr> ok, now it builds, but .pyx files are still not in /home/user/Desktop/chunkedbuffer/.tox/py36/lib/python3.6/site-packages/chunkedbuffer

[19:44:04] <pyusr> should I look for it somewhere else ?

[19:44:52] <pyusr> hmm... works

[19:44:53] <pyusr> THANKS

[19:45:03] <pyusr> ohh, not really

[19:45:58] <pyusr> the .pyx show up as 100% coverage, which is wrong

[19:47:34] <pyusr> any ideas why ?

[19:48:35] <pyusr> is this the correct tox.ini command: commands = pytest --cov={toxinidir}/chunkedbuffer --cov={toxinidir}/tests --cov-append --cov-report=term-missing {posargs}

[19:49:59] <pyusr> is this a bug in coverage or something else not configured properly ?

[19:50:48] <pyusr> I've updated the repo, now running tox shows wrongly coverage

[19:51:08] <pyusr> (but atleast the .pyx show up, and it builds properly without shaningens)

[19:51:34] <pyusr> btw, where is that "chunkedbuffer" dir in my disk now ?

[19:55:16] <toad_polo> pyusr: When I ran it I got "100% coverage" but for `__init__.py` and `test_buffers.py`, the pyx files didn't show up.

[19:55:18] <toad_polo> They don't show up in the site-packages directory because they aren't being installed, because they're not code you can run, they need to be compiled - only the compiled artifacts get installed.

[19:56:07] <pyusr> toad_polo: did you try to clone the latest repo ? they do show up now

[19:56:10] <pyusr> but with 100% which is wrong

[19:56:11] <toad_polo> They don't need to be installed, but in this case I guess you want them to be installed because the coverage plugin expects them to be next to the `.so` files (which will happen if you use `usedevelop`).

[19:56:44] <pyusr> yes, we've been in this discussion witih ngoldbaum before, but this isn't what is happening

[19:57:50] <toad_polo> Why is `isolated_build` commented out in the latest version?

[19:58:06] <pyusr> because when I added the pyproject.toml to MANIFEST.in it fixedit

[19:58:09] <pyusr> shoudl I keep it ?

[19:58:38] <toad_polo> You must keep it yes.

[19:58:44] <pyusr> ok

[19:58:45] <toad_polo> Those are two totally different things.

[19:58:59] <pyusr> yey, it works ~!

[19:59:23] <pyusr> rofl, I think you figured I have no clue what I'm doing, but thanks for the help !!!

[19:59:27] <pyusr> ngoldbaum and toad_polo !

[20:00:09] <toad_polo> pyusr: You still need to do work on the MANIFEST.in.

[20:00:33] <toad_polo> Open `.tox/dist/chunkedbuffer...tar.gz`

[20:00:54] <pyusr> ohh, I C

[20:01:00] <toad_polo> Mine includes a virtualenv which is not great, but also it includes .c files.

[20:01:00] <pyusr> sec, I'll fix it

[20:01:17] <toad_polo> That's why the MANIFEST.in I sent you has a bunch more lines.

[20:01:25] <toad_polo> They weren't for decoration :P

[20:03:07] <toad_polo> Weirdly this is taking forever for me to run `tox` on this, but that might be some weird thing in my setup.

[20:03:09] <pyusr> hmm.. your manifest.in still causes chunkedbuffer.egg-info/ to be created, is that ok ?

[20:03:22] <pyusr> nah, it takes long time here as well :)

[20:03:57] <toad_polo> I don't think it's supposed to take that long.

[20:04:00] <pyusr> (to be inside the sdist)

[20:04:05] <toad_polo> Anyway, yeah I dunno about that egg-info thing.

[20:05:04] <toad_polo> I actually think the `.egg-info/` line isn't doing anything in that MANIFEST.in.

[20:05:20] <ngoldbaum> if it’s non-trivial cython code it might be line tracing overhead

[20:05:23] <toad_polo> I think it's supposed to be reversed: `recursive-exclude * *.egg-info/`

[20:05:25] <pyusr> maybe *.egg-info/ ?

[20:05:28] <ngoldbaum> easily factor of 100 slowdowns

[20:05:56] <toad_polo> ngoldbaum: The slow part is the installation.

[20:06:19] <toad_polo> I think it's spending a lot of time copying stuff over into temporary files.

[20:06:24] <pyusr> ngoldbaum: should I have inside my sdist tarball the dir "chunkedbuffer.egg-info" ?

[20:06:40] <pyusr> toad_polo: for getting the coverage up, I don't need to run tox each time :)

[20:06:51] <toad_polo> pyusr: You should.

[20:07:06] <pyusr> I know, but it's slow :)

[20:07:15] <toad_polo> It shouldn't be.

[20:07:44] <pyusr> it installs cython + rebuilds the source with tracing each time

[20:07:49] <pyusr> that takes the majority of the time

[20:08:11] <ngoldbaum> sounds wrong

[20:08:44] <pyusr> regarding the egg-info ?

[20:10:01] <toad_polo> It seems weird to me that it would be that slow for ~500 lines of Cython.

[20:10:20] <pyusr> toad_polo: I did recursive-exclude * *.egg-info/ but it's still there

[20:10:55] <toad_polo> I expect it to be slower than incremental builds (which aren't used as an unfortunate side-effect of the way pip works right now), but for something this small it shouldn't be so bad.

[20:11:07] <toad_polo> pyusr: I wouldn't get hung up on it.

[20:11:19] <toad_polo> Open an issue on your repo to look into it, it's not going to hurt anything I don't think.

[20:11:19] <pyusr> k, it's not like someone is gonna use this code anytime soon anyhow :)

[20:12:29] <pyusr> well, now I can go to sleep, knowing tomorrow I can work on coverage finally :)

[20:12:33] <pyusr> thanks for all the help

[20:12:34] <pyusr> g'night

[20:13:17] <pyusr> if you have ideas why it's so slow, I'll come by tommorow, to see if I'm doing something stupid there

Log file Viewer

Help | Karma | Search:

#pypa logs for Friday the 10th of April, 2020