4 ms·

I'm a relative newcomer to python. I've been successfully using pip, and more recently pip+virtualenv to install packages. There haven't been many speedbumps so

I'm a relative newcomer to python. I've been successfully using pip, and more recently pip+virtualenv to install packages. There haven't been many speedbumps so far, though I'm not hitting the system that hard. I do miss the "Gemfile" type of abstraction that Ruby or CocoaPods provides. That said, the other day I tried to figure out how to package a bit of code I wanted to make reusable. It was a complete clusterfk. No two documents gave the same instructions, the instructions I did find were confusing and incomplete, and there was no obvious place to figure out what the "state of the art" of python packaging is. I still want to package this module up, but it doesn't seem worth the effort so far.

batgaijin 14y ago
well, since python is so much more readable than ruby you can just hand out a .py :P I usually write python and just moved to ruby, and as much as I like python I don't think anyone brings DSLs into the conversation as much as it should be.
- kennywinker 14y ago
  The whole advantage of packaging is `pip install mypackage`, which you don't get with a raw .py. and my module has a couple of non-.py resources contained. I really really really really really really hate DSLs. That's part of why I like Python more than Ruby. I want to learn one consistent language, not dozens of magic keywords that apply only in certain situations. I recognize that there is a place for them, it's just that in my mind that place is called "Ruby". ;)
ianb 14y ago
If you have a "simple" package, i.e., Python-only, and no namespace fanciness, find a setup.py from a package you use, copy it, scan and rewrite it, and you are probably good to go. Just avoid: - Namespace packages. This is where you have one package that provides, say, mypackageset.thing1, and another package that provides mypackageset.thing2. If you really want to have a "brand" with many packages in it, just name it mypackageset_thing1 and save yourself a headache. - If you have important non-.py files (e.g., templates) in your package, you'll have to learn package_data (http://docs.python.org/2/distutils/setupscript.html#installing-package-data http://docs.python.org/2/distutils/setupscript.html#installi...) and maybe MANIFEST.in. These are annoying, and you won't notice when you install from a checkout or with "pip install -e". You might need to study up more on this thing in particular (or just poke around until it works). - Some people use requirements.txt instead of install_requires inside setup.py now. I often use both – but with install_requires just for the absolute minimum of what might be required.

batgaijin 14y ago

well, since python is so much more readable than ruby you can just hand out a .py :P I usually write python and just moved to ruby, and as much as I like python I don't think anyone brings DSLs into the conversation as much as it should be.

kennywinker 14y ago
The whole advantage of packaging is `pip install mypackage`, which you don't get with a raw .py. and my module has a couple of non-.py resources contained. I really really really really really really hate DSLs. That's part of why I like Python more than Ruby. I want to learn one consistent language, not dozens of magic keywords that apply only in certain situations. I recognize that there is a place for them, it's just that in my mind that place is called "Ruby". ;)

ianb 14y ago

If you have a "simple" package, i.e., Python-only, and no namespace fanciness, find a setup.py from a package you use, copy it, scan and rewrite it, and you are probably good to go. Just avoid: - Namespace packages. This is where you have one package that provides, say, mypackageset.thing1, and another package that provides mypackageset.thing2. If you really want to have a "brand" with many packages in it, just name it mypackageset_thing1 and save yourself a headache. - If you have important non-.py files (e.g., templates) in your package, you'll have to learn package_data (http://docs.python.org/2/distutils/setupscript.html#installing-package-data http://docs.python.org/2/distutils/setupscript.html#installi...) and maybe MANIFEST.in. These are annoying, and you won't notice when you install from a checkout or with "pip install -e". You might need to study up more on this thing in particular (or just poke around until it works). - Some people use requirements.txt instead of install_requires inside setup.py now. I often use both – but with install_requires just for the absolute minimum of what might be required.