Log file Viewer

[08:12:14] <underyx> hey there!

[08:12:51] <underyx> I'm completely new to python packaging, so I'd like to ask if what I'm planning is even viable at all before looking into anything really deep

[08:13:22] <underyx> I have a project which has a bunch of submodules, and I'd like to package all these separately

[08:13:56] <underyx> that is, I'd like to be able to selectively install foo.bar and foo.baz on different machines

[08:14:23] <underyx> having packages such as foo-bar, foo-baz, foo-common, etc. distributed via an internal package index

[08:59:01] <underyx> okay, what I've done so far is refactor our codebase to have the subpackages neatly separated into foo/common, foo/bar, foo/baz directories

[08:59:39] <underyx> they reference each other as foo.common for instance

[09:01:07] <underyx> if I have separate setup.py files as foo/common/setup.py and so on, am I going to be able to install the packages under the main foo package?

[09:01:39] <underyx> so that I can keep the foo.common references

[09:14:58] <underyx> I assume this is the correct way to go? https://pythonhosted.org/setuptools/setuptools.html#namespace-packages

[09:41:03] <apollo13> underyx: If you can work with pyhton3.4 I'd use their namespaces features

[09:41:12] <apollo13> I'd stay away from setuptools namespaces as far as possible

[09:41:17] <underyx> sadly I'm bound to 2.7

[09:42:26] <underyx> apollo13 that doesn't sound very reassuring, though :D

[09:43:12] <apollo13> wasn't ment to be reassuring :þ

[09:43:41] <mgedmin> underyx, namespace packages work sufficiently well in practice; https://github.com/ZopeFoundation has a bazillion of working examples

[09:44:09] <mgedmin> underyx, you need one line in setup.py like https://github.com/zopefoundation/zope.schema/blob/master/setup.py#L93

[09:44:31] <mgedmin> underyx, and you need your foo/__init__.py to have a magic incantation: https://github.com/zopefoundation/zope.schema/blob/master/src/zope/__init__.py

[09:44:59] <mgedmin> all of the packages that share the top-level package name have to do those two things

[09:45:40] <underyx> right, so for each subpackage, I need to place them in that bogus main package

[09:46:04] <underyx> and then doing an import will just look through all these fake main packages to see if the submodule is in there?

[09:46:06] <mgedmin> you could always decide to go for different top-level namespaces: foo, foo_bar, foo_baz, like the Pyramid project decided to do

[09:46:43] <apollo13> I'd do that till I can use py3.4 :)

[09:46:43] <mgedmin> oh, speaking of setuptools namespaces: you can't have any real code in foo/__init__.py

[09:46:59] <mgedmin> it's strictly 'declare-namespace-and-stop'

[09:47:02] <underyx> alright, I can do with that

[09:47:21] <underyx> apollo13 I wouldn't dare do that right now

[09:47:34] <underyx> so far our massive enterprise-ish codebase has been one large package

[09:47:58] <underyx> so all references to packages are written assuming that everything is under that one namespace

[09:48:30] <underyx> I think it'd be safer to just go with faking that same structure

[09:48:44] <mgedmin> same story with zope.*: one huge CVS repo (migrated to SVN at some point), eggsploded into small packages

[09:49:05] <underyx> well, if it worked for them

[09:49:09] <underyx> :D

[09:49:34] <underyx> thanks for the help, you two

[09:49:43] <underyx> I might check in with more questions later

[15:32:38] <hdeshev> Hi everyone

[15:33:05] <hdeshev> Is there a way to override a setup.cfg extension build option at `pip install time`? I need to get rid of a `define=SQLITE_OMIT_LOAD_EXTENSION` option in the pysqlite extension.

[15:38:42] <hdeshev> http://paste.pound-python.org/show/kF0CSteiShXnGHNUpnDh/ my horrible pip wannabe script that does the thing at the moment

[15:45:59] <hdeshev> Alright, I found the setup.py build_ext --undef option. Now all I need is get pip to pass it along.

[17:44:33] <zahlman> So, it turns out the issue I was having earlier with spaces in the path to pip is https://github.com/pypa/pip/issues/1997

[17:45:05] <zahlman> and I've also been having issues with cleanup of temp files, which is https://github.com/pypa/pip/issues/1744

[22:22:40] <zahlman> So... to get myself up to speed with the tools, I started by cloning pypa/sampleproject off github... I've now suddenly realized that instead of creating a new project, I have a branch of the sampleproject. What's the best way to clean this up?

[22:33:45] <carljm> zahlman: are you concerned about having sampleproject's history in your git history, or just about the "clone of ..." link displayed on github?

[22:34:13] <carljm> if it's just the latter, make sure you have a local clone that's up to date, delete the github repo, then recreate the github repo and push back into it from your local repo.

[22:34:30] <carljm> if it's the former, then do the same, but also locally copy all the files into a brand-new repo directory that you "git init"

[22:34:37] <carljm> before pushing back up to the new repo on github

[22:37:30] <zahlman> carljm: I'm only now attempting to set up the github repo, and I can't `git remote add origin` because there's already one.

[22:38:29] <tomprince> If that is all you care about, git remote set-url (sp?)

[22:40:05] <zahlman> "set-url"?

[22:40:07] <carljm> zahlman: yes, tomprince has the right spelling. "git remote set-url origin THE_URL" instead of "git remote add origin THE_URL"

[22:40:35] <carljm> you're just modifying your already-existing "origin" remote instead of adding one

[22:40:35] <aclark> or remove and readd the origin

[22:40:41] <carljm> or that.

[22:40:49] <zahlman> aha. Do the commits from the old project cause a problem though?

[22:40:54] <zahlman> other than licensing, I mean

[22:41:00] <carljm> zahlman: but you may want to consider whether either of the issues I mentioned above concern you, because if they do you should fix it now

[22:41:30] <carljm> zahlman: no, not really. just that anyone who explores the early history of your project will see them. if that doesn't bother you, there's not really a problem.

[22:41:46] <zahlman> >are you concerned about having sampleproject's history in your git history

[22:41:55] <zahlman> I'd like to get rid of them for aesthetic reasons, if it isn't too much effort

[22:42:09] <carljm> i outlined the effort above

[22:42:16] <carljm> make a new empty directory

[22:42:21] <carljm> run "git init ." in it

[22:42:41] <carljm> copy all the files from your cloned sampleproject repo into that directory (excluding .git/)

[22:42:46] <carljm> and then commit them.

[22:42:53] <carljm> no magic to it :-)

[22:43:10] <zahlman> and if I wanted to preserve *my* history... write a script or something? :/

[22:44:06] <carljm> oh, that gets a lot more complex

[22:44:24] <carljm> i'm sure it's possible, but it'll involve researching arcane git commands that I don't have committed to memory :-)

[22:45:41] <dstufft> git filter-branch

[22:45:44] <dstufft> or

[22:45:56] <carljm> but dstufft does!

[22:46:27] <dstufft> git rebase -i onto the very first commit and squash all the commits you don't want and just turn them into a general "import project" commit

[22:46:46] <dstufft> the second one is probably easier to do for a one off thing

[22:47:04] <zahlman> #git also mentioned rebase -i, so there's that

[22:47:39] <dstufft> there are some other things you could do which are slightly less manual effort, but are harder to explain

[22:51:06] <zahlman> at this point in my git experience, understanding things constitutes manual effort :)

[23:07:44] <tomprince> If you don't have any history, you could also do 'git update-ref -d refs/heads/master