Log file Viewer

[16:27:55] <ionelmc> koniiiik: that might have been simpler

[16:28:25] <ionelmc> koniiiik: they probably did it like that to reuse code, assuming setup_commands.py is shared between a number of projects

[18:16:36] <lucarval> I created an RPM package for my project, after I installed it, the install_requires dependencies were not installed. Is there a way to create an RPM package that includes my dependencies?

[18:26:13] <ionelmc> lucarval: you want to bundle the deps? instead of repackaging them as separate rpms?

[18:26:22] <ionelmc> hard to say without seeing your spec file

[18:28:51] <lucarval> ionelmc, I'm not sure if my suggestion is the best approach. My problem is that after installing the RPM, my module is broken because the dependencies were not installed.

[18:29:53] <lucarval> If I install with pip, then the dependencies are installed. But as an RPM those are lost.

[18:30:25] <ionelmc> lucarval: well, if you'd ask in #rhell you'll be brashly told that you need to package your deps as rpms

[18:31:04] <ionelmc> sorry, #rhel ;-)

[18:31:06] <lucarval> ionelmc, even if it's not a dependency that I wrote?

[18:31:23] <ionelmc> i think it depends

[18:31:49] <ionelmc> are you packaging an app? does it use a virtualenv? what other stuff you install on that machine?

[18:31:58] <ionelmc> details etc etc

[18:32:34] <lucarval> it's actually just a simple library that relies on zabbix-api (https://github.com/gescheit/scripts/tree/master/zabbix).

[21:04:57] <kober> Hey, I was just setting up a new VM for a few packages at work and I got this on every virtualenv: pkg_resources._vendor.packaging.markers.UndefinedEnvironmentName: 'extra' does not exist in evaluation environment.

[21:05:02] <kober> anyone know what that means?

[21:05:30] <kober> These are packages that currently work, are in production, and other developers are using just fine. I think its something related to being a new VM and maybe upgraded packages?

[21:56:16] <glyph> Is there a person I can be annoyed at here for unpublishing setuptools versions repeatedly? :)

[21:57:15] <Arfrever> glyph: What "unpublishing"?

[21:57:50] <glyph> Arfrever: On the Mimic project - https://github.com/rackerlabs/mimic - we use requires.io to track upstream dependency pins and move them forward

[21:58:22] <glyph> Arfrever: setuptools seems unique in its penchant for releasing a version, waiting until our CI has completed and the pull request succeeds, then, as the merge to master is running _its_ CI, the new setuptools version disappears from PyPI

[21:58:39] <glyph> for example

[21:58:57] <glyph> this PR <https://github.com/rackerlabs/mimic/pull/579> updated us to setuptools 20.6.4

[21:59:08] <glyph> that was then un-published and the current version is now 20.4.

[22:00:39] <glyph> Arfrever: does that make sense?

[22:00:50] <Arfrever> glyph: jaraco (who is making releases of Setuptools) quitted IRC 22 minutes ago.

[22:01:29] <glyph> Arfrever: Thanks.

[22:01:47] <glyph> Arfrever: I don't want to file a bug, because it's... not really a bug in setuptools :)

[22:02:21] <Arfrever> glyph: Some things about releases were discussed in #pypa-dev channel.

[22:02:56] <glyph> I wonder if I should just eliminate the setuptools pin here.

[23:26:59] <dbrecht> i'm currently working over a build pipeline proposal for python systems at work and am looking to confirm an assumption with a surface amount of digging: if i build a venv and install dependencies with it activated, i can ship that venv as a tarball and execute without needing to worry about activation so long as a) the build and target machine architecture matches, b) python from the venv is executed from top build dir level (i.e.

[23:27:00] <dbrecht> ./bin/python) as to pick up installed dependencies, and c) utilities such as pip that are dependent on the virtualenv are not used. are those assumptions correct, or is there more to it that i'm not seeing?

[23:55:43] <kennethreitz> dstufft fyi pypi.python.org says (c) 2015