Quoting https://www.pypa.io/en/latest/ {{{ They host projects on github and bitbucket, and discuss issues on the pypa-dev and distutils-sig mailing lists. }}} I don't know where to go to. ... Choices .... too many choices ..... ... giving me the feeling of uncertainty. I am feeling fear. I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction. Please help me. Regards, Thomas Güttler -- I am looking for feedback for my personal programming guidelines: https://github.com/guettli/programming-guidelines
On 29 March 2017 at 17:51, Paul Moore <p.f.moore@gmail.com> wrote:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
As far as I can tell, to get a customer experience instead of a prospective co-contributor one. I'm sorry Thomas, as long as you continue looking for a coherent customer experience from a collaborative collection of volunteer-run community projects, you're going to continually be confused and disappointed. The Python ecosystem *does* include commercial vendors that offer to make opinionated technical decisions on behalf of their customers, as well as providing a single point of contact for support questions and feature requests, but beyond that, offering an overwhelming array of confusing choices is pretty much the way open source *works*. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 29.03.2017 um 10:27 schrieb Nick Coghlan:
On 29 March 2017 at 17:51, Paul Moore <p.f.moore@gmail.com> wrote:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
As far as I can tell, to get a customer experience instead of a prospective co-contributor one.
You are right
I'm sorry Thomas, as long as you continue looking for a coherent customer experience from a collaborative collection of volunteer-run community projects, you're going to continually be confused and disappointed.
You are right
The Python ecosystem *does* include commercial vendors that offer to make opinionated technical decisions on behalf of their customers, as well as providing a single point of contact for support questions and feature requests, but beyond that, offering an overwhelming array of confusing choices is pretty much the way open source *works*.
You are right. Regards, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Am 29.03.2017 um 10:27 schrieb Nick Coghlan:
On 29 March 2017 at 17:51, Paul Moore <p.f.moore@gmail.com> wrote:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
As far as I can tell, to get a customer experience instead of a prospective co-contributor one.
I'm sorry Thomas, as long as you continue looking for a coherent customer experience from a collaborative collection of volunteer-run community projects, you're going to continually be confused and disappointed.
The Python ecosystem *does* include commercial vendors that offer to make opinionated technical decisions on behalf of their customers, as well as providing a single point of contact for support questions and feature requests, but beyond that, offering an overwhelming array of confusing choices is pretty much the way open source *works*.
My frustration has reached a limit. Yes, I am willing to pay money. Which vendor do you suggest to give me a reliable package management? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
On 30 March 2017 at 18:53, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
Am 29.03.2017 um 10:27 schrieb Nick Coghlan:
The Python ecosystem *does* include commercial vendors that offer to make opinionated technical decisions on behalf of their customers, as well as providing a single point of contact for support questions and feature requests, but beyond that, offering an overwhelming array of confusing choices is pretty much the way open source *works*.
My frustration has reached a limit. Yes, I am willing to pay money.
Which vendor do you suggest to give me a reliable package management?
For cross-platform use cases, the best known options are ActiveState, Enthought, and Continuum Analytics (with the latter two focusing primarily on data analysis tasks). Another option if you're looking to bundle your own applications is PyRun, from eGenix: http://www.egenix.com/products/python/PyRun/ Finally, if you're solely interested in Linux, then Python runtimes are generally covered by commercial Linux support agreements. However, exactly which of the available commercial support options will be the best fit for your needs will depend on what you're aiming to do, and how it aligns with their product offerings. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mar 30, 2017, at 1:53 AM, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
My frustration has reached a limit. Yes, I am willing to pay money.
Which vendor do you suggest to give me a reliable package management?
You may want conda -- it's an open source project, and you can get commercial support through Continuum Analytics. Though conda, and Continuum was born in the data science / scientific computing world, there is nothing about conda specific to data science. It's just that computational computing poses extra challenges for packaging -- but the easy stuff is still easy. And the conda-forge project provides an open source way to support a larger community. -CHB
On 6 April 2017 at 01:52, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
On Mar 30, 2017, at 1:53 AM, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
My frustration has reached a limit. Yes, I am willing to pay money.
Which vendor do you suggest to give me a reliable package management?
You may want conda -- it's an open source project, and you can get commercial support through Continuum Analytics.
Though conda, and Continuum was born in the data science / scientific computing world, there is nothing about conda specific to data science. It's just that computational computing poses extra challenges for packaging -- but the easy stuff is still easy.
PayPal Engineering put together a decent write-up of their path towards adopting that model last year: https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/ It's definitely a reasonable way to go for organisational infrastructure, but even conda doesn't cover all the potential use cases that are out there (something I discuss a bit in http://www.curiousefficiency.org/posts/2016/09/python-packaging-ecosystem.ht... ) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Apr 5, 2017 at 6:41 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
PayPal Engineering put together a decent write-up of their path towards adopting that model last year: https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/
Thanks for that link. We're a much smaller shop, but have had pretty much the same experience -- also really good to see them mention miniconda at the end -- I think that's a much better way to go for most folks than the whole Anaconda pile. It's definitely a reasonable way to go for organisational
infrastructure, but even conda doesn't cover all the potential use cases that are out there
of course not -- nothing does, but I would add to the contents of that post: The conda-forge project is a Major boon to the conda infrastructure -- there is now a robust way for the community to expand the available number of packages (and keep up more recent versions). And anyone can take advantage of that infrastructure for their own (selfish?) needs: Chances are, there will be a package or two that you rely on that is not in conda defaults (maintained by Continuum) or currently in conda-forge. So you can pip-install those few -- but what if they aren't on PyPi either? or are hard to compile and install with ugly dependencies? You can contribute build recipes to conda-forge, and then have it for you, and all your users, and the rest of the world to access. Much better than hand maintaining stuff yourself. My pain point now is still full multi-platform support. conda has package versions that are platform independent, but it can still be hard to get everything built in the same version on all platforms, so it does get a bit ugly. But no other solution makes that better anyway. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Thursday, April 6, 2017, Chris Barker <chris.barker@noaa.gov> wrote:
On Wed, Apr 5, 2017 at 6:41 PM, Nick Coghlan <ncoghlan@gmail.com <javascript:_e(%7B%7D,'cvml','ncoghlan@gmail.com');>> wrote:
PayPal Engineering put together a decent write-up of their path towards adopting that model last year: https://www.paypal-engineering.com/2016/09/07/python-packaging-at-paypal/
Thanks for that link.
+1
We're a much smaller shop, but have had pretty much the same experience -- also really good to see them mention miniconda at the end -- I think that's a much better way to go for most folks than the whole Anaconda pile.
It's definitely a reasonable way to go for organisational
infrastructure, but even conda doesn't cover all the potential use cases that are out there
of course not -- nothing does, but I would add to the contents of that post:
The conda-forge project is a Major boon to the conda infrastructure -- there is now a robust way for the community to expand the available number of packages (and keep up more recent versions). And anyone can take advantage of that infrastructure for their own (selfish?) needs:
Chances are, there will be a package or two that you rely on that is not in conda defaults (maintained by Continuum) or currently in conda-forge. So you can pip-install those few -- but what if they aren't on PyPi either? or are hard to compile and install with ugly dependencies? You can contribute build recipes to conda-forge, and then have it for you, and all your users, and the rest of the world to access. Much better than hand maintaining stuff yourself.
Someone still needs to commit to maintaining the conda package; otherwise who knows whether this is the latest stable release?
My pain point now is still full multi-platform support. conda has package versions that are platform independent, but it can still be hard to get everything built in the same version on all platforms, so it does get a bit ugly.
Docker images are reproducible and archivable: https://github.com/ContinuumIO/docker-images - https://github.com/ContinuumIO/docker-images/blob/master/miniconda3/Dockerfi... - https://github.com/ContinuumIO/docker-images/blob/master/anaconda3/Dockerfil... https://github.com/jupyter/docker-stacks - https://github.com/jupyter/docker-stacks/blob/master/README.md#visual-overvi... - https://github.com/jupyter/docker-stacks/blob/master/base-notebook/Dockerfil... - a diff miniconda setup - https://github.com/jupyter/docker-stacks/blob/master/base-notebook/Dockerfil... - ARMv would be cool too (e.g. for raspberry pi) https://github.com/Kaggle/docker-python - https://github.com/Kaggle/docker-python/blob/master/Dockerfile - everything and the kitchen sink What platforms does conda-forge auto-build for? - [x] x86[-64] - [ ] linux-armv7l - https://github.com/conda-forge/conda-forge.github.io/issues/269
On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner <wes.turner@gmail.com> wrote:
Chances are, there will be a package or two that you rely on that is not
in conda defaults (maintained by Continuum) or currently in conda-forge. So you can pip-install those few -- but what if they aren't on PyPi either? or are hard to compile and install with ugly dependencies? You can contribute build recipes to conda-forge, and then have it for you, and all your users, and the rest of the world to access. Much better than hand maintaining stuff yourself.
Someone still needs to commit to maintaining the conda package; otherwise who knows whether this is the latest stable release?
Indeed. and it it's a not-that-widely-used package, then you will have to do that yourself -- but using the conda-forge infrastructure makes that (relatively) easy. In contrast -- who knows whether the package on PyPi is the latest stable release? Hopefully the maintainer is keeping it up, but if not, you're kinda dead in the water.
My pain point now is still full multi-platform support. conda has package versions that are platform independent, but it can still be hard to get everything built in the same version on all platforms, so it does get a bit ugly.
Docker images are reproducible and archivable:
In a way Docker, as I understand it, is orthogonal to this conversation. And when I talk about "all platforms", I mean running natively on all platforms -- I can't give my Windows users a Linux VM and expect them to know what the heck to do with it. Not that Docker isn't a really useful tool to htlep address some of these problems... -CHB
What platforms does conda-forge auto-build for? - [x] x86[-64]
linux-64 win-32 win-64 osx-64 (all Intel) - [ ] linux-armv7l
- https://github.com/conda-forge/conda-forge.github.io/issues/269
looks like folks are trying, but it's not really there yet -- mostly due to the lack of easy to access CI services for armv7I It's an open-source project -- if it's important to someone, it will get done. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Fri, Apr 7, 2017 at 4:58 PM, Chris Barker <chris.barker@noaa.gov> wrote:
On Thu, Apr 6, 2017 at 5:34 PM, Wes Turner <wes.turner@gmail.com> wrote:
Chances are, there will be a package or two that you rely on that is not
in conda defaults (maintained by Continuum) or currently in conda-forge. So you can pip-install those few -- but what if they aren't on PyPi either? or are hard to compile and install with ugly dependencies? You can contribute build recipes to conda-forge, and then have it for you, and all your users, and the rest of the world to access. Much better than hand maintaining stuff yourself.
Someone still needs to commit to maintaining the conda package; otherwise who knows whether this is the latest stable release?
Indeed. and it it's a not-that-widely-used package, then you will have to do that yourself -- but using the conda-forge infrastructure makes that (relatively) easy. In contrast -- who knows whether the package on PyPi is the latest stable release? Hopefully the maintainer is keeping it up, but if not, you're kinda dead in the water.
So then there's pulling from a specific source rev: pip install -e git+ssh://git@github.com/pypa/pip@9.0.1#egg=pip There was a discussion about adding the git/hg/svn/vcs source URI to each package's metadata: - "add "sourceURL" to the metadata 3.0 PEP." https://www.mail-archive.com/distutils-sig@python.org/msg25836.html https://www.mail-archive.com/distutils-sig@python.org/msg25833.html - Project-URL - Source-URL (metadata 2.0) AFAIU, the only way to read the package version from the {git, hg, } source repository is to run the setup.py. There's a semver way to specify the vcs revision ("git short SHA") in the package identifier: https://github.com/openstack-dev/pbr/pull/14/commits/5b7a619046eb10ed3fa7bb9...
My pain point now is still full multi-platform support. conda has package versions that are platform independent, but it can still be hard to get everything built in the same version on all platforms, so it does get a bit ugly.
Docker images are reproducible and archivable:
In a way Docker, as I understand it, is orthogonal to this conversation. And when I talk about "all platforms", I mean running natively on all platforms -- I can't give my Windows users a Linux VM and expect them to know what the heck to do with it.
IIUC, this should work w/ Docker for {Linux, Windows, OSX, }: docker run -i -t continuumio/miniconda3 /bin/bash AFAIU, If you instead wanted to run Windows containers on a Windows host, you'd need Windows Server 2016: https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-star... You can run "provisioner(s)" (shell script, salt states, ansible playbooks) at image build time with e.g. Packer: https://www.packer.io/docs/basics/terminology.html With a configuration management tool like salt or ansible, you can define configuration policies with conditionals for whichever given platform specs (and see it all in one place as "infrastructure as code").
Not that Docker isn't a really useful tool to htlep address some of these problems...
-CHB
What platforms does conda-forge auto-build for? - [x] x86[-64]
linux-64 win-32 win-64 osx-64
(all Intel)
- [ ] linux-armv7l
- https://github.com/conda-forge/conda-forge.github.io/issues/269
looks like folks are trying, but it's not really there yet -- mostly due to the lack of easy to access CI services for armv7I
It's an open-source project -- if it's important to someone, it will get done.
Raspberry Pi support for conda-forge would probably be really useful for education. IDK what sort of resources would be needed to add Pi2's to the CI build farm?
Am 08.04.2017 um 01:51 schrieb Wes Turner:
AFAIU, the only way to read the package version from the {git, hg, } source repository is to run the setup.py.
I see. This is the only way at the moment. Let's look back. How was this in the past? Maybe five years ago? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
Thomas Güttler <guettliml@thomas-guettler.de> writes:
Let's look back. How was this in the past? Maybe five years ago?
That's a very vague question. What kind of answer do you want? Is it one you have an answer for already; and if so, what is the point of your question here? I don't doubt that you *have* a point. What I doubt is the value to others here of asking something that demands a lot of to even find out what you mean. -- \ “[T]he question of whether machines can think … is about as | `\ relevant as the question of whether submarines can swim.” | _o__) —Edsger W. Dijkstra | Ben Finney
Am 29.03.2017 um 09:51 schrieb Paul Moore:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
To find canonical docs. With "canonical" I mean current docs from the upstream. Regards, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
On 29 March 2017 at 10:31, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
Am 29.03.2017 um 09:51 schrieb Paul Moore:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
To find canonical docs. With "canonical" I mean current docs from the upstream.
I think Nick's point probably covers this discussion, but you haven't said what you want docs *for*. pip? setuptools? wheel? something else? They are in various places, which you can hunt out via pypi or google. It's not hard to do, but certainly it's true that it's harder to find things than you'd want if you were paying for a well-documented service. But given that you're not paying anything, and no-one working on Python packaging has any obligation to meet your expectations, you'll need to either lower the level of your expectations, pay someone to provide what you're looking for, or offer your own time and energy to address the issues you find. Simply making vague complaints on this list isn't particularly productive. Sorry if that's not the response you were hoping for, and in particular if you have a pressing need for support that we're not providing, I do understand how that can be a problem for you, but as Nick says, this is the reality of relying on software that's provided to you free of charge. Paul
Am 29.03.2017 um 11:47 schrieb Paul Moore:
On 29 March 2017 at 10:31, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
Am 29.03.2017 um 09:51 schrieb Paul Moore:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
To find canonical docs. With "canonical" I mean current docs from the upstream.
I think Nick's point probably covers this discussion, but you haven't said what you want docs *for*. pip? setuptools? wheel?something else?
If you are wearing new comer glasses, you don't know exactly what you are looking for. If you would know that, then you would be an expert. And then you don't need a guiding hand.
They are in various places, which you can hunt out via pypi or google. It's not hard to do, but certainly it's true that it's harder to find things than you'd want if you were paying for a well-documented service. But given that you're not paying anything, and no-one working on Python packaging has any obligation to meet your expectations, you'll need to either lower the level of your expectations, pay someone to provide what you're looking for, or offer your own time and energy to address the issues you find. Simply making vague complaints on this list isn't particularly productive.
The complaint is vague? Here is it more precise: Quoting https://www.pypa.io/en/latest/ {{{ They host projects on github and bitbucket, and discuss issues on the pypa-dev and distutils-sig mailing lists. }}} Why two repo providers, why two mailing lists. This confuses new comers. I think this is precise feedback.
Sorry if that's not the response you were hoping for, and in particular if you have a pressing need for support that we're not providing, I do understand how that can be a problem for you, but as Nick says, this is the reality of relying on software that's provided to you free of charge.
Yes, Nich is right. Regards, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
On 30 March 2017 at 08:36, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
Why two repo providers, why two mailing lists. This confuses new comers.
I think this is precise feedback.
Because there is more than one project, and because the topics of discussion are different on the two. Paul
On Mar 30, 2017, at 4:07 AM, Paul Moore <p.f.moore@gmail.com> wrote:
On 30 March 2017 at 08:36, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
Why two repo providers, why two mailing lists. This confuses new comers.
I think this is precise feedback.
Because there is more than one project, and because the topics of discussion are different on the two. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
To expand upon this a little more, PyPA is not really a formal organization where we dictate top down about how projects must operate. About the only requirements we have are that your project relates in some way to Python’s packaging toolchain and that you accept being bound by our CoC. Beyond that projects under the PyPA banner are operated independently of each other with their own policies and procedures and such. It provides some loose organization and a “brand” but that’s really about all, so while most projects have opted to use GitHub, not all of them have (and that’s ok!). The two mailing lists are *largely* historical really, there was a time when distutils-sig (and before that even, catalog-sig) was not a particularly pleasant place to discuss things at and as such it made sense to try and sequester yourself away from it for some kinds of discussions. This has gotten a lot better in recent years and *most* mailing list like discussion tends to happen here on distutils-sig. Couple that with the fact that the individual projects tend to use their issue trackers to hold discussions that are specific to their particular project and we could probably consolidate, but I also don’t think it’s a big deal either. — Donald Stufft
2017-03-29 2:31 GMT-07:00 Thomas Güttler <guettliml@thomas-guettler.de>:
Am 29.03.2017 um 09:51 schrieb Paul Moore:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
To find canonical docs. With "canonical" I mean current docs from the upstream.
Are you aware of https://packaging.python.org/ ?
Regards, Thomas
-- Thomas Guettler http://www.thomas-guettler.de/
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 30 March 2017 at 01:27, Jelle Zijlstra <jelle.zijlstra@gmail.com> wrote:
2017-03-29 2:31 GMT-07:00 Thomas Güttler <guettliml@thomas-guettler.de>:
Am 29.03.2017 um 09:51 schrieb Paul Moore:
On 29 March 2017 at 06:29, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
I am stupid and missing a guiding hand which gives me simple straight forward step by step instruction.
To do what?
To find canonical docs. With "canonical" I mean current docs from the upstream.
Are you aware of https://packaging.python.org/ ?
As an opinionated-but-still-free combination of tools, there's also Kenneth Reitz's pipenv: https://github.com/kennethreitz/pipenv Understandably, that's mainly geared towards network service hosting environments like Heroku, but it also works pretty well for command line apps, testing environment setups, etc. However, none of the available options will get away from the fact that only end users know their own operational requirements - we can't provide a single universal right answer, because there isn't a single universal use case. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (9)
-
Ben Finney -
Chris Barker -
Chris Barker - NOAA Federal
-
Donald Stufft -
Jelle Zijlstra -
Nick Coghlan -
Paul Moore -
Thomas Güttler -
Wes Turner