Date: Sun, 1 Jun 2014 00:51:07 +0200 From: Marcus von Appen <mva@FreeBSD.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: python@freebsd.org Subject: Re: Question on virtualenv (python) and FreeBSD Message-ID: <20140531225107.GA56181@medusa.sysfault.org> In-Reply-To: <538A41D5.8020203@freebsd.org> References: <538A2A5F.2000601@freebsd.org> <20140531195031.GA854@medusa.sysfault.org> <538A41D5.8020203@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On, Sat May 31, 2014, Alfred Perlstein wrote: > On 5/31/14 12:50 PM, Marcus von Appen wrote: > > On, Sat May 31, 2014, Alfred Perlstein wrote: > > > >> I have details and a workaround on my blog here (less messy than pasting > >> the entire 200+ lines of info into this message): > >> http://splbio.wordpress.com/2014/04/19/using-djangosqlalchemy-and-virtualenv-on-freebsd/ > >> > >> Basically it seems that because we don't by default ship sqlite with > >> Python we wind up with this odd situation where the virtualenv'd Python > >> can't be used for the apps that I tend to use. > >> > >> I'm wondering can something be done to make virtualenv work better out > >> of the box for people? > > Shouldn't that be rephrased to "make virtualenv work better out of the box > > with my applications requiring package X?" > > > > Sorry for nit-picking here. We strip certain parts of a Python default > > installation, which others might or might not do. One could create a FAQ, what > > to watch or which additional packages are recommended for installation. Right > > now, I do not see a huge issue here, though. > > > > If this is a problem that someone sees as more critical for users, we should > > rethink the customized Python installation process, which however also means > > that users would have to install more dependencies, when they just want a > > simple Python interpreter. > > No problem with nit-picking here. In the opposite direction I wouldn't > say "my", I would say "the majority of people using python in web > stacks" which is huge these days. Basically the suggested way of > setting up django and sqlalchemy does not work via the HOWTOs for Linux > and OS X that are out there without what appears to be somewhat hard to > figure out commands to "fixup" the virtualenv install. They target Linux and OS X, not BSD and not Windows, either ;-). > As far as a huge issue, I actually see one, the recommended way to do > apps these days is using these virtual containers, that being virtualenv > under python and rvm under ruby. > > In fact it's the best way to make your apps easily distributable across > your org. This depends on the org and distribution method. > At the end of the day taking a look at what other OS's are doing and how > the HOWTOs are structured would go a long way to getting FreeBSD more > traction in the webstack community, this is not only my opnion, but the > opinion of the younger people on my team who suggested that I bring this up. > > They, the younger devs on my team would not have the time nor > inclination to debug this and would simply say "lol, I guess it's time > to download ubuntu where this howto will work". For them the OS is a I could write a lot in response to that... > tool that should just work, not really what they are all that interested > in for day to day. The fact that I get to hack on FreeBSD is a product > of FreeBSD being a great platform for these python apps. The problem is not about the OS, but about a *tool* they want to use. That's a huge difference, when it comes to maintenance. Our py-sqlite3 installation depends on databases/sqlite3, which is highly configurable and, depending on the purpose of the host and other applications, may need special care. Given your venv approach, the admin might update sqlite3 in a slightly different way, effectively breaking your app - since you lack control over it, even with venv (I won't mention installing django from ports, since you know that way well enough and probably evaluated the pros and cons against venv and your production and dev environments already). > Sorry for the harsh words, it's not intended, I'm just not sure how to > otherwise express the need here for us to support these stacks out of > the box. Create a toolchain for them, which deals with all necessary bits, e.g. a shell script, doing something like the following: 1) check for pythonXX and py-sqlite3 being installed on the host 2) create venv 3) copy/link the py-sqlite3 bindings into venv (or adjust venv's path), if necessary > A few questions, but feel free to comments on all: > 1) Does the concept of a "python-lite" port make sense where the default > is a larger subset of the default python packages you get on other > machines? We have the python-lite port already as default, if one may say so. sqlite3, gdbm, tkinter and bsdbb are stripped from it. How about adjusting your server or dev host installations and to add sqlite3 and friends to the installation? Would that be sufficient or otherwise problematic? > -Or- > 2) perhaps we should simply just add sqlite as that seems to be the only > blocker I've seen thus far to get this working for the two important web > stacks? See above for the dependency chain. I see a risk here for pythonXX to be updated on every sqlite update. Is that really necessary, if we only speak about a single port to be installed on the host? > 3) do we care about making it out-of-the-box easy for people running web > services/stacks like django and sqlalchemy+flask on FreeBSD in the > recommended fashion? Define "recommended fashion". According to [1] I do not see any contradiction in your method to install everything. In fact, one recommended way on FreeBSD is to use the ports. > 3) other? > > thank you Marcus. I won't block the process in either direction here, since I am generally pretty indifferent about pulling in sqlite3 as dependency for lang/python. It is wide-spread enough that it would end up on a majority of web application systems anyway (although most large-scale web apps probably will use a scalable database back-end, such as mysql, pg or oracle). Which brings me to the target group for your request: it'd be (mostly) developers, not? Which would bring me to the toolchain script and FAQ and responsibility over the dev machines again :-). [1] https://docs.djangoproject.com/en/dev/intro/install/ Cheers Marcus --SLDf9lqlvOQaIe6s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iEYEARECAAYFAlOKXNsACgkQi68/ErJnpkczMACeIUustyO9NY2trqBYd2+eDDdQ bYEAoK68pg+e/zs429nBQ1IGZJj+vYCC =Cd0v -----END PGP SIGNATURE----- --SLDf9lqlvOQaIe6s--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140531225107.GA56181>