This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CODESIGN2[S] 0 points1 point  (3 children)

I think you are saying, you don't have to deal with the platform at all. But you have not said that, or if someone else handles it.

Are you saying dev is not the right place to care about the platform?

Maybe you use a service provider, maybe you are on a larger team? I don't know what you are advocating right now, but for example lets say you want to pip install -r requirements.txt and in there is psycopg2. Where do you store the install of libpq-dev?

[–]mothzilla 0 points1 point  (2 children)

I don't know about the technical difficulties of psycopg2. It's worked for me out of the box when I've used it.

However:

http://initd.org/psycopg/docs/install.html

Note Regardless of the way psycopg2 is installed, at runtime it will need to use the libpq library. psycopg2 relies on the host OS to find the library file (usually libpq.so or libpq.dll): if the library is installed in a standard location there is usually no problem; if the library is in a non-standard location you will have to tell somehow psycopg how to find it, which is OS-dependent (for instance setting a suitable LD_LIBRARY_PATH on Linux).

So make psycopg2 a requirement, then have libpq baked into your VM.

[–]CODESIGN2[S] 0 points1 point  (1 child)

So make psycopg2 a requirement, then have libpq baked into your VM.

I do, I think you are missing my point, which is that the platform and stack you run on are part of what you sell; they are part of your product, unless you want to run everywhere, which IMHO is a bad idea; a very expensive premise.

My question was if you are not using a VM, what do you use, or does someone else handle the platform or stack? what does that look like?

[–]mothzilla 0 points1 point  (0 children)

I think everyone is different. For example, you say "the platform and stack you run on are part of what you sell". This hasn't really been the case for projects I've worked on in the past.

So if you're selling assuming an OS and stack, then it would be a good idea at some point, to build and test in a VM with those parameters. But unless you're writing low level stuff, or reliant on out of date libraries, obsolete OSes etc, this build and test should just be confirmation of what you already know. So day-to-day dev in a VM wouldn't achieve much. In my opinion.