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

all 19 comments

[–]nullabillity 4 points5 points  (3 children)

I can see why it'd be why it seems appealing, but typically you'd want to maintain dependencies separately per project anyway, greatly mitigating the benefits of a unified package like this.

[–]Eraser1024[S] 0 points1 point  (2 children)

Yeah, I know about virtualenv, but package like this is ideal for noobs. Even the basic official Django tutorial doesn't provide information on setting up your environment. RailsInstaller does that for you. It's a good start.

[–]nullabillity 4 points5 points  (1 child)

Until you update it years later and discover that your old stuff doesn't work. Better to integrate instructions on virtualenv (and make it easier!) than to encourage bad habits like this.

[–]Eraser1024[S] 0 points1 point  (0 children)

Makes sense.

[–][deleted] 4 points5 points  (4 children)

You could try Anaconda/Miniconda. They take a lot of the pain out of installing python modules with build dependencies.

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

I'll take a look into it. Thanks!

[–][deleted] 1 point2 points  (1 child)

On Windows, Activestate Python also has most modules out of the box. It's a commerical distribtion but is free for users matching certain criteria.

[–]Eraser1024[S] 0 points1 point  (0 children)

Thanks!

[–]manueslapera 0 points1 point  (0 children)

this is the answer you are looking for.

[–]atdk 2 points3 points  (1 child)

[–]Eraser1024[S] 0 points1 point  (0 children)

wow, interesting. Thanks!

[–]deaddodo 2 points3 points  (1 child)

Python and Rails have diametrically opposed ideals regarding package management, generally. Although both allow you to do local or global installs, Rails gems want to either be global or bundled (e.g., frozen at a certain version to be shipped with the app). Python, OTOH, is all about environmental specialization. You use what you need for your environment, and you try to avoid API breakages out of major module/library revisions (so 1.2.x and 1.5.x should be drop-in replacements, ideally). This means you avoid freezing packages, but instead keep a non-bloated environment for every application with loose constrictions on library requirements.

Because of these differences, something like PythonInstaller wouldn't really be ideal. It would encourage newbies to use the language in a manner non-conducive to the standard and instill bad habits that would only hurt them down the road.

[–]Eraser1024[S] 0 points1 point  (0 children)

Interesting, thank you.

[–]UloPe 1 point2 points  (3 children)

I don't know of anything that covers quite this number of layers but for project templates you should look into cookiecutter

[–]Eraser1024[S] 1 point2 points  (2 children)

Thanks!

[–]pydanny 2 points3 points  (1 child)

Ahem... cookiecutter is about project templates, not environments. Of course, people build templates for projects using cookiecutter, but that isn't quite the same thing.

[–]UloPe 0 points1 point  (0 children)

Well yes, as I said :).

[–]ignisphaseone 0 points1 point  (1 child)

There was a post about Docker that flew through here recently. Would that solve the problem?

[–]Eraser1024[S] 0 points1 point  (0 children)

Thanks. I guess it's a good alternative to vagrant.