> Otherwise, whatever $ which python will be the default. This is a bit strange because the python binary is always supposed to be Python 2. The Python 3 binary is supposed to be named python3. Some distributons don't follow this, but they're the weird non-conformant ones; it's not a behaviour that should really be relied on.
Non-conformant? PEP-394 says that scripts should only use python in the shebang if it's compatible with both py2 and py3, and be updated to work with both, or to use python2 otherwise.
Announcing Pipenv
161–170 of 171 posts
Re: Announcing Pipenv
#162Earlier quoted context omitted.
Okay - maybe I'm missing something, but pip is the only Python package manager I've ever used. And it's basically "pip install xxx", "pip install --upgrade xxx", "pip show xxx", "pip list", "pip uninstall xxx" I'm curious what I've been missing about pip that makes it problematic - I've never used the other tools you mentioned (setuptools/distutils/ez_install) - so I can't comment on them, but, on the flip side, I've…
One things is a good dependency management. Right now if you want to upgrade your Python version, or one of your packages, it's a mountain of manual work. There is nothing in the stack helping you with the dependency graph. Another thing is providing a stand alone build. Something you can just ship without asking the client to run commands in the terminal to make it work. I use nuikta ( http://nuitka.net/ ) for this.…
you can't easily move virtualenvs
Re: Announcing Pipenv
#163Earlier quoted context omitted.
Could you provide some specific examples of the "shocking" difference?
Python best practice: figure out the correct directory structure by reading docs and looking at GitHub repositories, learn how to write setup.py & setup.cfg & requirements.txt & MANIFEST.in files, setup py.test and tox (because Python 2 still lives), write your README in RST format (as used by nothing else ever), and for bonus points: write your own Makefile. Get depressed when you realize that target platforms eithe…
Thank you. It is exactly what I have asked for.
The Python best practice: you do not need "correct directory structure" to start programming in Python--there is no boilerplate structure to create (and that would require a tool): REPL, Jupyter notebook in a browser, a single file (module) is enough in a simple case.
There is no single "correct directory structure" for more complex cases either e.g., a Django web app and Ubuntu's Appindicator would probably have different structures and it is likely that there are tools that create corresponding project skeletons such as "django-admin startproject mysite".
Usually, the packaging/deploying are not nice & neat and differ depending on your project, chosen platform--either you follow an example or you have to study a never ending list of incomplete/contradicting standards/semi-documented rules & conventions--it is unrelated to Python (even if tools such as Ansible, Salt are implemented in Python). Naturally, there are things that can be improved.
btw, reStructuredText is a great text format for documenting Python projects (it scales from a simple README.rst to a whole book). You can always convert README.md written in your favorite Markdown flavour using pandoc or a similar tool. Markdown is great for a short human-generated plaintext content common on Github, Stack Overflow.
Re: Announcing Pipenv
#164Earlier quoted context omitted.
Python best practice: figure out the correct directory structure by reading docs and looking at GitHub repositories, learn how to write setup.py & setup.cfg & requirements.txt & MANIFEST.in files, setup py.test and tox (because Python 2 still lives), write your README in RST format (as used by nothing else ever), and for bonus points: write your own Makefile. Get depressed when you realize that target platforms eithe…
Thank you. It is exactly what I have asked for. The Python best practice: you do not need "correct directory structure" to start programming in Python--there is no boilerplate structure to create (and that would require a tool): REPL, Jupyter notebook in a browser, a single file (module) is enough in a simple case. There is no single "correct directory structure" for more complex cases either e.g., a Django web app a…
> there is no boilerplate structure to create (and that would require a tool): REPL, Jupyter notebook in a browser, a single file (module) is enough in a simple case.
Rhetorical question: is Python a scripting language or an applications language?
If it's a scripting language, then yes, a single file is all that you need. Otherwise, you need a directory structure with various support files to be able to create and build your CLI tool or library, and you need to follow conventions if you are going to publish your work as Open Source. Which in turn requires you to know which tools to use, and what they require.
Go raised the bar here, I think. Rust and .NET Core both follow the Go idea of having one top level tool that gives you what you need to test and package your library or CLI application. That means that new users can get success with at least two basic use cases very rapidly and with little effort. Which in turn means that the previous status quo is no longer so tolerable.
> btw, reStructuredText is a great text format for documenting Python projects (it scales from a simple README.rst to a whole book).
Sure, the big problem with RST is that it lost the fight. Every developer who uses GitHub has to know a little Markdown, not RST or something else. For larger documents, AsciiDoc is probably the thing. I used to be a Textile loyalist, myself, but stopped fighting against the tide and switched to Markdown some years ago.
Re: Announcing Pipenv
#165Earlier quoted context omitted.
Thank you. It is exactly what I have asked for. The Python best practice: you do not need "correct directory structure" to start programming in Python--there is no boilerplate structure to create (and that would require a tool): REPL, Jupyter notebook in a browser, a single file (module) is enough in a simple case. There is no single "correct directory structure" for more complex cases either e.g., a Django web app a…
> there is no boilerplate structure to create (and that would require a tool): REPL, Jupyter notebook in a browser, a single file (module) is enough in a simple case. Rhetorical question: is Python a scripting language or an applications language? If it's a scripting language, then yes, a single file is all that you need. Otherwise, you need a directory structure with various support files to be able to create and bu…
Python is a general -purpose programming language. No size fits all.
You've ignored "in a simple case" and ignored the next paragraph that discussed "more complex cases." If I have a task: publish Ubuntu PPA with a package that does X, or deploy a web app on a PaaS, or add a component that massages some data for a numerical simulation on a cluster or something else. I do not see what Go, Rust, .NET do here that Python can't.
Obviously, there could be specific use-cases where some language/framework has advantages over other languages/frameworks and (as I said) there may be use-cases that can be improved that why they should be named explicitly -- that is why I've asked in the first place -- so far I don't see "shoking difference" in the general case (I don't doubt that you had experienced the shoking difference for your specific (unnamed) task).
Re: Announcing Pipenv
#166Earlier quoted context omitted.
> there is no boilerplate structure to create (and that would require a tool): REPL, Jupyter notebook in a browser, a single file (module) is enough in a simple case. Rhetorical question: is Python a scripting language or an applications language? If it's a scripting language, then yes, a single file is all that you need. Otherwise, you need a directory structure with various support files to be able to create and bu…
Python is a general -purpose programming language. No size fits all. You've ignored "in a simple case" and ignored the next paragraph that discussed "more complex cases." If I have a task: publish Ubuntu PPA with a package that does X, or deploy a web app on a PaaS, or add a component that massages some data for a numerical simulation on a cluster or something else. I do not see what Go, Rust, .NET do here that Pytho…
My original comment was specifically about building a CLI tool, which I did as a learning exercise to practice writing a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI.
Please bear in mind here that I did this because I wanted to learn and follow current best practices, with a project that I specifically picked because it would not require 3rd-party libraries or big frameworks to muddle things.
I don't think that it was dissatisfying because Python is a general-purpose programming language, but because the process currently happens to involve an assortment of different tools, piecing together scattered information, and being willing to suffer a few paper cuts like Python versions and multiple old file formats. That was my experience building a simple Python 3 application, and it didn't leave me eager to do it again.
We can discuss how Go-style tooling and packaging can also help with the cases that you mentioned, but I didn't really want to stray off into an extended analysis. My original points were just that the overall developer experience that new Python users currently get compares poorly to some other languages, and that is totally fixable. I hope that things do improve, and feel that Pipenv is a very welcome move in that direction.
Re: Announcing Pipenv
#167Earlier quoted context omitted.
Python is a general -purpose programming language. No size fits all. You've ignored "in a simple case" and ignored the next paragraph that discussed "more complex cases." If I have a task: publish Ubuntu PPA with a package that does X, or deploy a web app on a PaaS, or add a component that massages some data for a numerical simulation on a cluster or something else. I do not see what Go, Rust, .NET do here that Pytho…
My original comment was specifically about building a CLI tool, which I did as a learning exercise to practice writing a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI. Please bear in mind here that I did this because I wanted to learn and follow current best practices, with a project that I specifically picked because it would not require 3rd-party librari…
You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better.
What is so bad about "a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI."
Put __init__.py in a directory and you've created a Python package where you could add as many modules including other packages as you like.
Copy-paste setup.py ("pip init" like "npm init" would help here), update it with your info and to upload a wheel to PyPI, run:
$ pip install twine
$ python setup.py sdist bdist_wheel
$ twine upload dist/*
I didn't read it but as far as I understand all of this is on one page https://packaging.python.org/distributing/
Re: Announcing Pipenv
#168Earlier quoted context omitted.
My original comment was specifically about building a CLI tool, which I did as a learning exercise to practice writing a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI. Please bear in mind here that I did this because I wanted to learn and follow current best practices, with a project that I specifically picked because it would not require 3rd-party librari…
You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better. What is so bad about "a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI." Put __init__.py in a directory and you've created a Python package where you could add as many modules including other packages as you like. Copy-paste setup.py ("pip init" like "npm ini…
> You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better.
I gave you a breakdown in my earlier comment, but I'm thinking that writing more isn't going to make this better:
* Your experience: Python does everything that you need, and quickly, because you are already very proficient in the language and the tools. * My experience: Shopping for a programming language, knows Python syntax but no attachment beyond that, has tried out a number of languages and has working knowledge of their tooling.
I'm not suggesting that Python is a bad language, just that I think that the tooling and developer experience for new users is not competitive with some other languages. If you are proficient in Python, and haven't tried other languages recently, you won't have experienced the jump: Python is slightly more hard work than Ruby or Node.js, but Rust, Go and .NET Core have a level of slickness and integration that older platforms just don't have.
> What is so bad about "a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI."
Again, see my previous comment for a list, including some bits that you are omitting. I found that document and read it, but it assumes that you have already created something with docs and tests (laid out in an appropriate directory structure). Since I didn't actually submit the package to PyPI, I didn't have to think about twine, but that's another paper cut. Which is my main point: if someone is not already sold on Python, every small quirk and special case becomes another obstacle, and the Python tooling has collected more than a few.
Re: Announcing Pipenv
#169Earlier quoted context omitted.
This. Particularly the need for a minimum standard project structure. Pipenv shows its pedigree and looks like a great tool...that also overlaps significantly with conda. What are the use cases that Pipenv addresses better than/in lieu of conda?
You don't need to install (ana|mini)conda just to get a package manager, would be why I would use Pipenv over Conda. Miniconda alone requires somewhere close to 400MB of space and comes with a whole bunch of extra things I don't need just to manage packages and virtualenvs.
Don't you mean 45MB windows, and 21 MB OSX?
Re: Announcing Pipenv
#170Earlier quoted context omitted.
You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better. What is so bad about "a multi-file Python project that could act as a library as well as a CLI, and be packaged as a wheel for PyPI." Put __init__.py in a directory and you've created a Python package where you could add as many modules including other packages as you like. Copy-paste setup.py ("pip init" like "npm ini…
> You says "X is bad", "Y is better" but you don't say how exactly X is bad, in what way Y is better. I gave you a breakdown in my earlier comment, but I'm thinking that writing more isn't going to make this better: * Your experience: Python does everything that you need, and quickly, because you are already very proficient in the language and the tools. * My experience: Shopping for a programming language, knows Pyt…
It shouldn't be that hard to demonstrate "shocking" difference in experience.
Could you provide an explicit list of what do you mean by "a breakdown in my earlier comment"? (obviously, I wouldn't ask for more information in my comments if your previous comments were specific enough) e.g., in language X I can do Y using command Z but Python requires A,B,C instead (implying that Z is "shockingly" better than doing A,B,C).
As I understand, the issue is that you want the structure of a project in a language X to be generated for you by a single command (whatever the project) or that this command must be available by default.
I've googled "python create command-line project template":
$ pip install -U cookiecutter
$ cookiecutter https://github.com/audreyr/cookiecutter-pypackage.git