Log file Viewer

[15:27:33] <raydeo> what is the recommended way to produce a wheel?

[15:28:01] <raydeo> this is like the 2nd or third release of pyramid I've messed up by not deleting my build folder prior to bdist_wheel and artifacts from other builds creep into the wheel (but not the sdist!!!!)

[15:28:11] <raydeo> </rant>

[15:29:06] <ngoldbaum> raydeo: twine upload dist/* ?

[15:29:26] <raydeo> that's not part of building the wheel

[15:30:14] <ngoldbaum> you're just doing "python setup.py bdist_wheel"?

[15:30:28] <ngoldbaum> perhaps it's a bug that that doesn't check for artifacts from other builds first

[15:30:31] <raydeo> python setup.py sdist bdist_wheel

[15:30:37] <raydeo> and yes, it's a bug

[15:31:09] <raydeo> bitbucket.org/pypa/wheel/issues/147/bdist_wheel-should-start-by-cleaning-up apparently I even commented on it months ago :(

[15:33:16] <helppls> I'm trying to run github.com/skorokithakis/catt but i can't get it to run, the pip install worked at least

[15:34:52] <helppls> I see a ~/.local/lib/python3.5/site-packages/catt directory but i don't know how to run it..

[15:35:26] <ngoldbaum> is there are catt script in ~/.local/bin?

[15:35:34] <ngoldbaum> if so, is ~/.local/bin in your PATH?

[15:35:49] <helppls> YES THANKS

[15:36:07] <ngoldbaum> ubuntu doesn't put ~/.local/bin in the default PATH because reasons

[15:37:51] <helppls> Thank you so much, that was the solution. if only it was easier to find tbh

[15:42:06] <ngoldbaum> if you want, there's a bug in the ubuntu bug tracker about this

[15:42:09] <ngoldbaum> has been open for years

[15:54:45] <Wooble> tbh, surprised it's not closed as "wontfix; anything worth running should be installed with apt, so ~/.local is useless"

[15:55:51] <ngoldbaum> it doesn't help that they patched pip to make --local the default

[15:55:54] <ngoldbaum> again, because reasons

[16:01:23] <Siecje> Are there plans to have a recommended dependencies?

[16:30:05] <tos9> Siecje: Recommended for what?

[16:30:44] <ngoldbaum> e.g. optional dependencies i think

[17:20:53] <Siecje> tos9: Yeah, not require to used by provide additional functionality.

[17:22:25] <ngoldbaum> Siecje: how is that different from extras_require?

[17:22:41] <utek> this week if full of 'bug in tracker that's opened for years'

[17:24:04] <utek> Siecje: you can do `pip install libname[extra]` already

[17:31:28] <ronny> raydeo: my preffered method of generating a release artifact is a clean deploy step at a ci that starts with a clean slate

[17:31:41] <ronny> (see the deploy for travis in setuptools_scm for example)

[17:36:22] <raydeo> ronny: in principle I think it's nice but I don't like the idea of multiple release managers sharing the same pypi credentials on projects where more than one person may issue releases

[17:37:54] <ronny> raydeo: well, pypi wont get api token based acces until a while so i#ll have to stick with normal automation

[17:38:12] <ronny> raydeo: for my use case, its fine ti put my credentials into a travis secret

[17:38:37] <ronny> raydeo: but basicaly if you release via a ci system, you dont get people making releases anymore

[17:40:30] <raydeo> sure... it's just the pypi metadata that's wonky then

[17:41:06] <Siecje> ngoldbaum: utek: Thanks I will look into it.

[17:41:49] <raydeo> it looks great for projects managed by just one person

[18:15:22] <dstufft> raydeo: you can set a MANIFEST.in that explicitly excludes those artifacts... but IIRC pyramid doesn't want a MANIFEST.in

[18:16:15] <raydeo> that ... no ...

[18:16:31] <raydeo> we'd have a manifest.in built up over time excluding anything we ever deleted from the repo

[18:18:52] <raydeo> we wouldn't be able to trust a single recursive-include in the manifest

[18:20:31] <raydeo> either 1) wheel starts listening to setuptools-git (probably not going to happen) 2) wheel starts cleaning the build folder first or 3) there's another way to create a wheel from the sdist? I don't really see another option to make it reproducible

[18:21:27] <raydeo> option 3 is probably best but I do not know how to do it

[18:55:34] <raydeo> ronny: does setuptools-scm replace setuptools-git? I can't find anything saying one way or the other and they are both listed as beta

[18:57:23] <raydeo> I'm not interested in the versioning aspect, just the auto-manifest generation

[19:32:23] <dstufft> raydeo: untar the sdist and run setup.py bdist_wheel?

[19:35:55] <raydeo> dstufft: I think that works as a possible approach, thanks

[22:28:47] <ronny> raydeo: im the author of setuptools_scm and i did put it under pypa - im not affiliated with setuptools-git

[22:29:32] <ronny> raydeo: but setuptools_git is only a subset of setuptools_scm