Dustin,
Yeah, you sure have. I reached out to the puppetagain/releng list (and
maybe also puppet-users) a few months ago when I first started this
project. Your advice was probably pretty much the same, so I hope my
replies are.
On 01/14/2014 09:25 PM, Dustin J. Mitchell wrote:
> I could have sworn I've said some of this before, but I'm not sure
> where. So sorry if this is repetitive.
>
> First, I think what your implementation is missing is a resource name
> that's globally unique to the host. Let's say I want to install
> different versions of sqlalchemy in /venvs/staging and /venvs/prod. I
> need some resource name to distinguish those three resources. The
> best option I can think of is to munge the virtualenv and package name
> together into a string:
>
> Package { provider => 'pip' }
> package {
> '/venvs/staging::sqlalchemy':
> version => '0.8.6';
> '/venvs/prod::sqlalchemy':
> version => '0.7.9';
> }
This is certainly technically feasible, and simple, but I find it to
be... for lack of a better term, ugly. Putting something like this in a
manifest, let alone a forge module, makes me shiver. And, more to the
point, I'm not sure I'd stand up and recommend that it be endorsed by pypa.
>
> You could introduce a new type, or maybe shoe-horn this into the
> existing type, where an unqualified package name would be installed
> systemwide. You'd need to pick your delimiter carefully -- don't take
> '::' as a recommendation :)
Unless someone pipes up and says, "hey, you could ... ", I think a new
type in a Forge module is how this will be headed. If I go down that
route, the module will only manage virtualenvs and the packages inside
them, it'll leave the python env up to something else.
>
> But another, entirely different approach may be to think of the
> virtualenvs as the resources, with the packages just a property:
>
> python::virtualenv {
> "/path/to/virtualenv":
> python => "/path/to/python",
> packages => [ "package==version", "mock==0.6.0",
> "buildbot==0.8.0" ];
> }
>
> In fact, that's exactly what the python module in PuppetAgain does[1].
That's actually what our current module is based on, albeit with a
handful of changes.
This works fine within a controlled environment. However, (a) it works
fine if you know all the packages that belong in the venv at one time,
in one place. It doesn't work if you (not saying this is the best idea)
need multiple classes to install packages in the same venv, or if you
need to determine dependencies based on other classes. More importantly
from my point of view though, (b) it loses Puppet's native ability to
log and report on changes to individual resources. The ability to easily
see when a given package is upgraded, or what version it's at, across an
entire infrastructure is incredibly powerful. Wrapping all of that up in
one defined type loses the data that comes along with native types, and
is so wonderfully easy to extract from PuppetDB. Also, though It's a bit
of an oddball issue, (c) I currently have use cases where puppet needs
to install packages in an already-existing, non-puppet-managed virtualenv.
>
> More generally, I find it helpful to design puppety things from the
> front back: start by asking "how do I want to use this from my other
> manifests", then work from there to the best and simplest means of
> implementing it.
>
> Dustin
>
> [1] https://wiki.mozilla.org/ReleaseEngineering/Puppet/Modules/python
> / https://github.com/mozilla/build-puppet/tree/master/modules/python
>
Thanks for the feedback. The RelEng python module provided the base of
what I'm using today, and was wonderful inspiration. But I'm trying to
move to a native type, in core or a module, that will hopefully become
the canonical way to manage pip/venv through Puppet.
-Jason
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/52D5FFA3.3040102%40jasonantman.com.
For more options, visit https://groups.google.com/groups/opt_out.
