Python packaging is good now - <AUTHOR> https://glyph.twistedmatrix.com/2016/08/python-packaging.html <comment><USER5> While this is all nice, I have yet to find a package system that is as straight forward to use as NPM.

Don't get me wrong, I love Python and I'm not so much a fan of NodeJS, as Python is so much better designed than JavaScript, even in time of ES6. But their NPM is really well designed. NPM alone gives NodeJS a competitve advantage over many other popular languages including Ruby (Gem) and Python (PIP).

For example, why does Python packaging need such a complicated bootstrapping process? Install ensure_pip, then the real pip, and on top of that virtualenv. NodeJS just ships with NPM. Done.

Any why do we need to create and manage a "virtualenv"? Why do you have to go through extra hassle just to avoid global installs? NPM just creates a local sub directory node_modules and automatically installs and removes from that. Global installs happen only if you really want it to (npm -g). But you usually don't.

The only central place at NPM is the package cache so it doesn't download things twice if you have two separate projects with similar dependencies. In the Python/PIP world, everything is central and even today you still have to accept extra hassle to get a sane, local setup.

<comment><USER6> I have yet to come across a scenario where installing a python library as global ended up being an issue in the python ecosystem. You either need it, or you don't. Short of some contrived scenario where a piece of code is not able to utilize a certain package's latest code and you have to juggle two different versions of that package. If I had something like that, I'd fix the code, not juggle old package versions or install all dependencies in my project's sub-folder.

> " _For example, why does Python packaging need such a complicated > bootstrapping process? Install ensure_pip, then the real pip, and on top of > that virtualenv._ "

It's not that complicated:

        sudo apt-get install python-pip python-dev build-essential

        sudo pip install --upgrade pip

Then you can install any python package to your heart's content with:

        pip install PACKAGE

You don't need virtualenv, nor do you need ensurepip.

>" _In the Python /PIP world, everything is central and even today you still have to accept extra hassle to get a sane, local setup._"

I think you may be coming at it from a javascript perspective where you expect it to work according to the way you're used to it working with Node/NPM. I have absolutely no hassle installing anything in the python/pip ecosystem. Except maybe MySQL and OpenCV, I'll grant you that. But those are separate discussions as they require external dependencies outside of python's packaging.

<comment><USER7> I've run into several issues with global installs because the Ubuntu maintainers have decided to make changes to libraries I want to use.

<comment><USER8> Ubuntu maintainer here. Can you be more specific, please? I'd like to understand if there was a general reason or if we're doing something that we should not be doing.

<comment><USER7> Appologies for my crappy memory, but the only case where I can remember the package was when I ran into issues with the PIL library being OS-managed and having basic functionality not working, and the answer I found that worked was installing it in a virtualenv. I also went through some chat logs of me complaining and I saw I had similar issues with urllib3.

The main issue is that they're modified at all, so they don't match up with the docs or what people say online, so until you realise that you're not running the normal code and need to run inside a virtualenv it's very confusing.

<comment><USER8> The only changes made to PIL in Ubuntu in any current release (Precise, Trusty, Xenial) are security fixes: [https://launchpad.net/ubuntu/+source/pillow](https://launchpad.net/ubuntu/+source/pillow).

> The main issue is that they're modified at all

Not modifying packages at all would also be a major issue. We'd end up shipping dysfunctional packages, or packages with major bugs, or not fixing bugs during the lifetime of a release.

Distributions do a ton of integration work that I think goes unnoticed by users. We routinely find issues and send them upstream - every development cycle. Users don't notice because they'll also find the bugfixes in upstream releases because we sent them there. But upstream releases don't all happen in lock-step, so we end up having to carry some patches to make everything work with everything else.

In the general case, we can't win. We'll always upset someone, which is why I asked for specifics. In general, we will:

(0) Avoid changing anything in a stable release, so users don't have things changed on them - except for (1).

(1) Fix bugs (including security bugs) as they are reported. Because of (0), this generally means that we cherry-pick fixes, which does cause some divergence from upstream. But if we don't do this, then other users complain either about the bugs or, if we pull everything into a package in an existing stable release, about things being changed under them.

(2) During development of a release we fix for integration issues, since every package in the distribution is expected to work with every other package - <USER2> (though with some exceptions) we generally only ship one version of each thing in a release. This means that we sometimes need to patch things (we prefer cherry-picks from upstream, but sometimes we don't get a response from upstream in time for our release schedule) in order to make everything work.

But in the specific case of PIL, we appear to not have had to do any of these things, except for some security fixes.

For urllib3, it looks like we had to make some modifications to fix security issues with regards to TLS and certificate verification in Trusty, and one bug in Xenial related to broken IPv6 square bracket handling, and that's it.

I don't really see how we can do anything different here. Should we have ignored the security issues and shipped vulnerable packages? Or should we have upset many more users of the stable release by bumping behaviour under the feet of existing deployments?

<comment><USER7> I'm not a Linux distro expert, I'm not even a python expert, all I noticed is that my code didn't work with the OS-managed PIL/urllib3 and installing the versions from pip in virtualenv fixed things. I don't know the reasons, just that was my experience. Maybe it was just the OS versions being old, I don't know.

The maintainer approach works well for everything you maintain, it just sucks for everything else, including installing out of repo software or writing your own software. It's made particularly bad by Python's packaging system which defaults to global installs.

FWIW, I lay this one more at the door of Python than I do Ubuntu, you guys are just dealing with their packaging system and I think that "Python packaging is a good now" is just ignoring the shitty parts.

Frankly it's easier for me to just always run my code inside a virtualenv than it is for you guys to make some drastic changes to make my life marginally easier, when I don't even really know what the problem was. It's just that this is a non-obvious thing to do for someone who hasn't been in the python ecosystem for long.

<comment><USER8> It sounds like all you needed was a newer version. Most distributions deliberately try to ship a version that was current at the time of release and don't update it later except for bugfixes. This is for the user stability reason I gave above. This is what a distribution release _is_ , and why many Ubuntu users prefer the LTS release over every six-monthly release.

If this is the case here, then this isn't a Python-specific problem at all. Developers have a choice: use the chosen distribution release version, or if that's not new enough, then find another way. For Python, one (commonly accepted and good) answer happens to be virtualenv. Many choose, because of their particular circumstances, to go all virtualenv and ignore distribution packages altogether.

Can I guess that you used an Ubuntu LTS, so you effectively opted in to packages that are older but don't change often?

Some solve this by never using a distribution version at all, which is fine. But understand that this is the nature of what a distribution is, and applies to the entire ecosystem, not just the Python one.

<comment><USER7> It's possible I had an old version, but I was trying to do super basic things with PIL on 14.04 LTS; literally just cropping a JPEG and things were failing.

Do I have this problem in Java/Node/Go/Rust? No, I don't.

The reason I don't have this problem is that dependencies are not installed globally, they are defined per-project and often statically linked in, there is no such thing as a conflict between two of those projects.

<comment><USER8> > It's possible I had an old version, but I was trying to do super basic > things with PIL on 14.04 LTS; literally just cropping a JPEG and things were > failing.

It sounds to me that you hit some kind of straightforward bug then, rather than some systemic issue.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Python packaging is great.

What's a bother is - as that article mentions - end-user deployments.

Now, I sort of have that down to a tee by using cx_freeze and Inno Setup, such that I can distribute my software to my end-users and all they have to do is click on a Setup.exe and my applications install just like any other Windows program.

I can do a similar thing on the Mac, but it's still a pain.

The main trouble with packaging Python applications up, is an apparent assumption (at least, that's the impression I have gotten over years of figuring out how to distribute my applications), that Python programs should all be open source - so for example, distutils assumes that the author wants his code to be readable by everyone who wishes to.

I wanted to be able to produce full applications and somehow compile and package them as in for e example, a C/C++ application.

The closest I can get to that currently, is cx_freeze, which isn't compilation, merely turning the Python code into bytecode.

Nuitka is showing lots of promise, but as yet it still cannot compile my applications into something usable (my really big Qt4 GUI applications either won't compile or there are lots of problems cropping up even if they do manage to run).

Here's hoping end-user deployment gets much easier than it is now, someday!

<comment><USER10> Could you explicate on your end-user deployment workflow a bit? I'm building a game in python and would love to distribute .exes to Windows players

<comment><USER9> Sure!

1) Develop your Python application ;)

2) I have a batch file build.bat which I use to build the deployment folder. This sits in the root directory of every application I develop, and is customised. It basically calls cx_freeze via the command line rather than bother with a setup.py file - I find this method far quicker and more convenient. An example...

      cxfreeze -OO -c CaptainsLog.py --include-modules lxml._elementpath,lxml.objectify,win32com.gen_py,requests.certs --base-name=Win32GUI --target-dir ..\CaptainsLog_DIST --icon CL_new_256.ico

This is for my Captain's Log program - a 3rd party application for use with the game Elite: Dangerous

cx_freeze will build and include all the necessary Python and Qt libraries to ..\CaptainsLog_Dist

I've had to ensure cx_freeze included some required stuff like lxml and those other things because for various reasons it didn't automatically include them when they were not specified, so be aware of that possibility when attempting to freeze your application.

3) I then can test whether the build/distribution works by double-clicking on the captainslog.exe file which cx_freeze has produced.

4) If all is well, I then run Inno Setup. I have a file captainslog.iss which I use and change as required (e.g. new version number). This will basically take everything which is in the CaptainsLog_DIST folder, and package it up into a suitably named Setup.exe file.

5) I then sign the Setup.exe file with my code signing certificate. Search google for how to obtain such - basically you need at least a Class II certificate from a suitable provider to prove your identity. I use a utility called ksign to do the actual signing.

6) I test the Setup.

7) All going well, deployment to my users is simply providing a download location - notification is built into my application (check for new versions), or if they disable that, peruse the game forums or my web site.

It's all been rather streamlined over a LOT of trial-and-error, frustration, and sometimes a lot of swearing. But the above works REALLY well for me and I use this workflow for bespoke software I write for paying customers.

It's a similar workflow (with some differences) for Macs.

The real beauty of it is that your end-users don't have to worry about installing Python, Qt, any of the Python dependencies/packages - <USER3> required to run the application is provided.

The other bonus is that you only need to worry about Python dependencies at /your/ end.

Note: when developing and deploying my applications, my entire toolset is the 32-bit versions - this ensures that your package will install and run on both older 32-bit and newer 64-bit versions of your target O/S.

Regards.

<comment><USER10> Thank you! Very helpful :)

</comment></comment></comment></comment><comment><USER11> In the past 12 hours, I started a new Python project. I can't agree with the sentiment - the most I can say is that Python packaging isn't terrible now.

My intention was to create a Python 3 package using best-practices, a nice division of labour by process to avoid threading problems, etc.

So far I've run into the following issues regarding packaging:

Getting started - there's a glut of documentation, much of it contradictory, much of it out-of-date. Simply google "Python packaging" and you'll have to pick between 4 sources of info on the first page, all of which look official.

The tools - this one was a new one for me; I normally use virtualenvs for development, but vaguely remembered it being bundled in Python 3. Turns out it's not virtualenv but "pyvenv". Beyond the confusion of the name change, there's also a tool called "pyenv" muddying the waters.

The specifics - I started with [https://packaging.python.org/](https://packaging.python.org/) and was struck by how ambiguous the instructions were. Doing something as simple as declaring your package's version has 7 different options: [https://packaging.python.org/single_source_version/](https://packaging.python.org/single_source_version/). In the end, I got the most help from reading the guide's sample project... I only have to wonder about the licensing implications of that.

The infrastructure - because I was creating a project with multiple executables, I needed a way to start one from the other. Despite knowing that setuptools is responsible for generating the executables, I quickly found that there's just no way to find those executable paths programmatically.

Library choice - I needed an inotify library. I searched for "inotify", "notify" and "watch" on Pypi but had little way of distinguishing the results - the "weight" column is useless as compared to a rating system or even download count. Thankfully, I remembered about awesome-python.com which bridges the gap.

All told, it took me several hours to bootstrap the project, not even including things like testing. I'd say Python packaging has a way to go before I'd call it "good".

<comment><USER12> I tend to use [0] for the boilerplate for getting started in writing a Python package. It was mostly used for Python 2.7, but I've written a few local Python 3.5 packages with it and everything seems to be fine (ie, "it worked on my machine - what could go wrong?").

I then use `nosetests -v` to run the tests.

[0] - github.com/ambitioninc/ambition-python-template

</comment></comment><comment><USER13> Is it?

On Debian there is Debian Python, and Debian pip. Then there is easy_install to install own pip, and that's different. virtualenv comes on top of all. Of course, there is Debian's Python packages, too.

On MacOS X with Macports, there is Apple's Python and Macports' Pythons, all with different pips. Of course, there is Macports' Python packages, too, for different Pythons.

</comment><comment><USER14> No matter what small tooling changes come about, the Python packaging ecosystem is fundamentally flawed, and will always be more complicated and less useful than others such as Maven (yes, Maven).

The primary reason is that setup.py, etc., have you download/manage one set of dependencies for _each project_ you're working on rather than simply housing all dependencies in a common folder, separated by version, as Maven does. It's pointlessly redundant. But the real pain comes when you start to install things. Since in Python land, dependencies for all tools are typically stored in the same folder, you very easily and quickly hit version conflicts since the dependencies are not really segregated by version. This leads to brutal bugs that creep on you at runtime when you realize, too late, that some tool you installed has dependencies that conflict with another.

What's worse, complex Python projects like OpenStack may have numerous dependencies which all in turn have differing and conflicting dependency versions of their own. Trying to keep them all in sync is a ridiculous exercise in time wasting and pointlessness, and problems caused by version mismatches are common.

The brilliant solution (sarcasm here), of course, is to create virtual environments with separate copies of every dependency for every tool we run. Again, pointlessly redundant and a pain to manage.

Is there a better way? Obviously. Use a single common repo with dependencies structurally segregated by version (ie: different folders), as is the way of doing things in Java-land. I know that Java-land stuff is bad and we're all supposed to hate it. But I've always failed to understand why developers in other language ecosystems continue to create tools in a vacuum, as if roadmaps for solving these problems don't already exist elsewhere. Look beyond your bubble. Hopefully one day the Python folks will catch on.

<comment><USER15> All of the CPAN-inspired packaging ecosystems are fundamentally broken. Including Maven.

> The brilliant solution (sarcasm here), of course, is to create virtual > environments with separate copies of every dependency for every tool we run.

Brilliant solution is to recognize that environments need to be packaged and managed too. No sarcasm. That's what nix does. And it makes package management a solved problem (ignoring current implementation-specific issues of course).

So, yes, there is a better way and it's nix [1] and guix [2] and the ideas behind them. Check them out.

[1] [https://nixos.org/nix/](https://nixos.org/nix/)

[2] [http://www.gnu.org/software/guix/](http://www.gnu.org/software/guix/)

</comment></comment><comment><USER16>
      The real takeaway here though, is that although it's still not
      perfect, other languages are no longer doing appreciably
      better.

Not sure how accurate is this.

At least not true in the context of OCaml/OPAM.

      As always, I'm sure none of this applies to Rust and Cargo is
      basically perfect, but that doesn't matter, because nobody
      reading this is actually using Rust.

So it seems that those using rust don't read HN:

[https://github.com/servo/servo](https://github.com/servo/servo)

[https://github.com/dropbox/rust-brotli](https://github.com/dropbox/rust- brotli)

\--

Bottom line: Bash everyone else arbitrarily and claim oneself to be the best!

<comment><USER17> [https://en.wikipedia.org/wiki/Hyperbole](https://en.wikipedia.org/wiki/Hyperbole)

</comment></comment><comment><USER18> > python setup.py sdist bdist_wheel

Wheels suck.

By using the bdist mechanism they make it impossible to build a single cross- platform, cross-Python package that just works. Wheels can't run 2to3 at installation so guess what? You have to make separate packages for Python 2 and 3.

There should be an easy way to have a pure Python package that "just works" on Python 2 and 3, 32-bit and 64-bit platforms without having to build separate packages. Right now that can only be done with the third-party Setuptools using sdist and a traditional setup.py. Distutils is still a half implemented packaging system. I wouldn't say that Python packaging is a solved thing.

<comment><USER19> You can easily build a single cross-platform, cross-Python wheel that just works. You just need to add "[bdist_wheel] universal=1" to your setup.cfg and write your code in a cross-Python style enabled by six and future ([https://pypi.python.org/pypi/future](https://pypi.python.org/pypi/future)).

<comment><USER18> Six is a third-party library and interferes with migration to Python 3. It requires you to tiptoe around the differences between 2 and 3. 2to3 is built in and does most of the heavy lifting for you. It should be possible to package Python code using the official Python distribution and nothing else.

<comment><USER19> > Six is a third-party library and interferes with migration to Python 3. It > requires you to tiptoe around the differences between 2 and 3.

That's a strange thing to say. Six and future were written to ease the migration to Python 3, and both are endorsed by the official Python porting guide ([https://docs.python.org/3/howto/pyporting.html](https://docs.python.org/3/howto/pyporting.html)). Meanwhile 2to3 is problematic because it complicates debugging and doesn't address issues like string handling, backports and other behavioral differences. Few popular Python libraries use 2to3, and most embrace the idea of single-codebase cross-version support.

I would agree that the Python core developers bungled the migration tools in the standard library, and I wish they were better. But as noted by the OP, library functionality in general is steadily becoming more decentralized, and six and future are the best options for packaging cross-version libraries today.

More generally, a lot of good work has gone into the wheels architecture, and it's a huge improvement on what we had before. If you think you can come up with something better, I would encourage you to try - the opportunity is there.

</comment></comment></comment></comment><comment><USER20> No discussion of python packaging without mention of conda is complete. It's as good as "apt-get" for Python (and not just for Python, but ... mostly for Python).

[http://conda.pydata.org/miniconda.html](http://conda.pydata.org/miniconda.html)

<comment><USER21> I believed that! Then I actually used it and got incompatible packages, packages only for 32 bit XOR 64 bit etc. It was not remotely as good as the package managers I am used to on several distros. :(

</comment></comment><comment><USER22> For a long time, PyPi intermittently reported extremely exaggerated download statistics and sometimes never even reported any statistics. Then they got bored of trying to fix it and removed it altogether, saying they want to concentrate on warehouse. I believe currently the only way to get any kind of statistics is to perform a query on Google's Big. Any attempt to talk about this issue results in the thread being locked and offended replies, and while I understand what it's like from the developer's point of view, the current state of things is completely unreasonable.

</comment><comment><USER23> It may well be. But one problem is all the references to all the various old ways that a first time deployer has to wade through. It took me quite a while to figure out what's current and what should be ignored, as well as what's old but still needs to be done, on a small project that I did to learn exactly this.

</comment><comment><USER24> Personal perspective of someone who's only used python 4 years and mostly in an linux ops capacity is that the packaging has always been pleasant to use and the few times I've had to install a node/ruby app as an end user have been comparatively horrible.

</comment><comment><USER25> This is the first time I've heard of ensurepip. It looks cool, but I'll wait until it becomes common knowledge before declaring that "Python packaging is good now", but I definitely agree that it's improving. I'll have to update my StackOverflow answer now to mention this. [http://stackoverflow.com/a/14753678/247696](http://stackoverflow.com/a/14753678/247696)

</comment><comment><USER26> "From 2008 to 2012 or so, Python packaging was a total mess."

Some things have improved, but fundamentally there really is not much difference in creating a package now vs. then.

A certain xkcd comes to mind.

</comment><comment><USER27> > _There should be tools that help you write and update a setup.py. Or a > setup.python.json or something, so you don't actually need to write code > just to ship some metadata._

There are some out there, e.g. OpenStack uses [https://pypi.python.org/pypi/pbr](https://pypi.python.org/pypi/pbr) \- it was pretty painful around the 1.0 transition when no two libraries seemed to be using compatible versions, but it hasn't caused me any trouble in quite a while now.

I'm more concerned by the lack of a (non-greedy) dependency solver in pip.

</comment><comment><USER28> While I agree with the fact that it isn't terrible as it once was; I personally can't say pip is really starting to look any better until the following is solved:

[https://github.com/pypa/pip/issues/988](https://github.com/pypa/pip/issues/988)

''Pip needs a dependency resolver''

Without such a thing you really don't quite have a way to ensure what you are requesting to be installed actually is a valid set of things.

</comment><comment><USER29> My main peeve is that distutils2 died, and with it, the idea of putting package metadata (author, version, dependencies) in `setup.cfg` instead of `setup.py`.

It's bad enough that I have a boilerplate `setup.py` that just does `import ConfigParser` and blasts the entire `[setup.py]` section into `setuptools.setup()` as ` __kwargs`. I copy and paste this boilerplate into every new project that I start.

Oh and while we're ranting about Python packaging, let me rant about tox, which is so-very-useful but also so-very-dangerous: IF YOU (SLIGHTLY) MISCONFIGURE YOUR TOX.INI FILE, IT WILL DELETE YOUR ENTIRE PROJECT DIRECTORY! [1]

I suppose I am getting too old and cranky for this stuff. :)

[1] [https://bitbucket.org/hpk42/tox/issues/352/tox-deleted- all-o...](https://bitbucket.org/hpk42/tox/issues/352/tox-deleted-all-of-my- code)

<comment><USER30> distutils2 may have died. The idea of declarative package metadata hasn't (although it may not have advanced as quickly as you might like). There is a PEP[1] (which is sadly not yet implemented[2]) which a) starts to move some metadata into declarative format b) is designed to allow implementation of alternative build systems that have more declarative metadata.

[1] [https://www.python.org/dev/peps/pep-0518/](https://www.python.org/dev/peps/pep-0518/) [2] [https://github.com/pypa/pip/issues/3691](https://github.com/pypa/pip/issues/3691)

</comment></comment><comment><USER31> The article say that with any recent python you can get started with a one liner:

       Python Core started distributing the ensurepip
       module along with both Python 2.7 and 3.3 ...

       $ python -m ensurepip --user

Tried here with python-2.7.11-3 and just got a traceback error.

Turns out according to one of the links given by the article[1] that this feature was actually not backported to these older versions of Python, apparently to encourage people to upgrade to new Python. This is unfortunate.

[1] [https://www.python.org/dev/peps/pep-0453/#including- ensurepi...](https://www.python.org/dev/peps/pep-0453/#including-ensurepip-in- python-2-7-and-3-3)

<comment><USER25> Which OS are you using? On Ubuntu, I get this useful output:

      $ python2 -m ensurepip --user
      ensurepip is disabled in Debian/Ubuntu for the system python.

      Python modules For the system python are usually handled by dpkg and apt-get.

          apt-get install python-<module name>

      Install the python-pip package to use pip itself.  Using pip together
      with the system python might have unexpected results for any system installed
      module, so use it on your own risk, or make sure to only use it in virtual
      environments.

<comment><USER32> It's upsetting that Ubuntu is so opposed to ensurepip that they won't even let it work in _user mode_. There is no way to use these Python standard library features without being root and installing separate Ubuntu packages.

This was Ubuntu bug #1290847, which is now marked as "Fix Released": they consider the current behavior okay.

Python packaging is good now, except on Ubuntu.

<comment><USER25> How does Debian do it?

<comment><USER8> The same people who look after Python in Ubuntu also look after Python in Debian (as part of a wider team) and also are active upstream in Python in making Python work well across all distributions.

Ubuntu is hardly on its own here. I recommend that anyone who disagrees with how Python is packaged on Debian and Ubuntu get in touch on the relevant mailing lists. If you think it's wrong, there's probably a use case you're missing, or you'll find that your proposal will badly break some other expected behaviour.

</comment></comment></comment></comment></comment><comment><USER23>
       $ python -m ensurepip --user
       $ python -m pip install --user --upgrade pip
       $ python -m pip install --user --upgrade virtualenv

> ...

> From here on out, now the world is your oyster; you can pip install to your > heart's content, and you probably won't even need to compile any C for most > packages. These instructions don't depend on Python version, either: as long > as it's up-to-date, the same steps work on Python 2, Python 3,

Nit: I suppose installing virtualenv works in 2 and 3, but hasn't venv in 3 made that unnecessary?

<comment><USER32> virtualenv has an advantage over venv, which is that people have spent years and years writing instructions for virtualenv, and not for the cases that venv handles slightly differently.

For example, with virtualenv you can choose to use a mix of globally- and locally-installed packages. With venv you can't. (You get global _or_ local, but not both.)

<comment><USER33> In that regard, venv is better. It's better to have a single place where you install your packages rather than a few different places, especially if you're working on a team. It would be hell to have a mix, not knowing exactly which goes where or why, and then explaining to another team member your setup in a coherent manner. It's much better to just know that your packages are either global or local and no in-betweens.

<comment><USER34> > It's much better to just know that your packages are either global or local > and no in-betweens.

The database driver and scipy are installed globally. Everything else is local to the environment.

Not hell at all, especially compared to compiling numpy/scipy every time you want to spin up a venv that uses a single feature.

Examples other than DB drivers and scipy exist. Compiling software isn't really that hard, but it's an unnecessary hurdle in many cases - <USER4> when you've already bought into an OS that does binary distributions specifically so you don't have to compile anything.

I'd be comfortable agreeing that any pure-python package should be venv only, but not that every package should be.

</comment></comment></comment></comment><comment><USER35> NPM did it right. PIP got it wrong. Requiring the same version of a library per application is really a bad idea.

It creates a lot of work to align your dependencies.

</comment><comment><USER36> The last three (cross-platform, Python 2 and Python 3) packages I published to PyPI have been Ctypes/Cython wrappers around Rust binaries. Yes, I'm a sample size of 1, but whatever, never let reality get in the way of your rhetorical blogpost, I suppose.

</comment><comment><USER37> I seem to feel more comfortable with redundant copies of libraries than virtual environments.

</comment><comment><USER38> I'd take pip over npm any day of the week. My experiences with Node have been horrible. Npm just grows okay but do not try to uninstall.

</comment><comment><USER39> A while back, I wrote some of my thoughts on Python packaging. I got excited seeing this title, but reading the article, I remain unconvinced. The whole thing is still way too confusing, and it's still not nearly as intuitive (or teachable) as "npm install ___".

<comment><USER19> Most of the things you said in your writeup were no longer true in February 2015, and I think there are no concrete things that you wrote that are true anymore, thanks to the hard work of Python packaging infrastructure maintainers ([https://github.com/pypa](https://github.com/pypa)).

I find the griping a bit over the top. The point of the OP is that new exciting improvements have arrived in the Python packaging infrastructure. Yes, there were many ugly overwrought things in setuptools' past. Yes, npm has several great ideas. npm is also much younger than setuptools/PyPI, and I can cite lots of horror stories from its pre-io.js days too. But the volunteers who got us this far deserve to be recognized for the progress they've made.

I think the biggest legitimate concern right now is how unintuitive it is to use pip in the presence of several Python runtimes/versions.

<comment><USER39> Yeah, I'm sure things are better. And your typical developer will probably be just fine (I mean, we know they are because Python is so popular!).

But for a beginner who is just trying to figure out how to share his or her code, it's still very confusing. And yes, part of that is definitely the fact that all of the mistakes of the past and their messy workarounds still show up in Google searches, muddying the waters; this obviously gives npm an edge. But even so, I feel that npm just does a better job when it comes to being learnable: people pick it up right away with very little trouble, and you can have your first "public-facing" module up on day one with very little effort. Indeed, in a way, the fact that it's so easy is what's giving it the most grief right now!

So there are definitely lessons to be learned there, for everyone.

</comment></comment></comment><comment><USER40> Funny that the PyPI web interface is down right now.

</comment><comment><USER41> That's a very good type face to read in mobile!

</comment><comment><USER42> I wish!

<comment><USER43> Could you elaborate on the issues you have with the current system?

<comment><USER44> Deploying a python application is still a horrible experience. My best attempts so far involve doing `pip wheel` during the build, then discarding anything that's platform dependent and fetching their source dists instead, then bundling that together with a script that sets up a virtualenv and installs all these dependencies and the project being installed ...

Compare to a jvm uberjar.

<comment><USER45> Except Python you can often run from git. Git pull do some pip done.

<comment><USER7> You can do the same things in Java land as long as you have used a build system written in the last decade such as Maven or Gradle, you can just as easily pull down a git repo and run mvn package

<comment><USER45> Well that is

a) A 30 sec - 10 minute process to build (vs 0 in python)

b) Weird because Java has a fatjar concept.

Python and Java are different. The easy path to deploy them doesn't need to be the same.

You may need to make them the same for ops sanity.. but if you are just doing 1 or the other, meh

<comment><USER7> > a) A 30 sec - 10 minute process to build (vs 0 in python)

Have you ever run someone else's python code? You have the exact same issue pulling down their requirements.txt, which is often not enough because you need to apt-get other libraries, try pip again, apt-get more, try pip again, etc.

> b) Weird because Java has a fatjar concept.

Sure, that's what you would do if you wanted to deploy an application to proc, my point was that it supports the same git checkout workflow if you want it to, which can be useful when dealing with other people's code and you want to make changes and not just run whatever jar they made.

</comment></comment></comment></comment></comment></comment></comment><comment><USER46> I don't know what this article is talking about. What is wrong with apt-get install python-something to install the python package called something? Or if it's not in the repositories, you checkout the library to a subdirectory of your project and call `import something` just like you would when apt-getting it.

So honest question, what's this easy_install stuff? Apt has been around since the nineties, just like python, and didn't change much as far as I know.

<comment><USER47> How would you then resolve the following scenarios:

1) I need to have two applications running on the same host with different Python versions. E.g. Python 2.6 and Python 2.7. apt would only support _one_ of the Python 2.x line installed at a time.

2) I need to have two applications that have conflicting version requirements on the same host. E.g. neither set of requirements can be installed at the same time.

3) I need to install a newer version of a Python library than the one in apt. If I install it into the system Python via pip, now apt is out of sync with what is actually installed.

4) I need to install a version of a Python library that conflicts with the requirements of system tools that rely on the system-installed Python. If I install said library, then the system tools will stop working / break down.

Also "checkout into your project directory and call `import`" doesn't scale. Maybe it works well for toy projects and one-off things, but not so much at scale.

<comment><USER48> > 1) I need to have two applications running on the same host with different > Python versions. E.g. Python 2.6 and Python 2.7. apt would only support one > of the Python 2.x line installed at a time.

I take it you haven't used Debian/APT for last three or four releases, because what you assert (only one Python 2.x version per host) is just plain invalid.

> 3) I need to install a newer version of a Python library than the one in > apt. If I install it into the system Python via pip, now apt is out of sync > with what is actually installed.

Uhm... I don't know why you have a problem with building your own package with the newer version. I do it all the time, for software both others' and mine.

This leaves points 2) and 4), which are essentially the same: how to install two conflicting versions of the same module for two different applications (one of which may come from the distribution), but this is not a problem with dpkg or RPM, this is a problem with Python's module lookup mechanism. For C libraries there are already good protocols for handling this issue (a little different for RPM and dpkg).

<comment><USER47> > Uhm... I don't know why you have a problem with building your own package > with the newer version. I do it all the time, for software both others' and > mine.

Maybe things have improved in the past few years, but last time that I built a dpkg for a Python library it was far from painless, even with some wrapper off the Debian wiki specifically for that use-case (and I was just doing this for pure-Python).

I've dealt with building both RPM and DPKG packages in the past, and I recall all of the build tools for each being far from ideal, and even the use case of "I want to package up a list of files and install them to a specific location" was far more difficult that it should have been. The biggest issue being that most of the tooling is based on the use-case of taking a tar of sources files, and running it though autoconf-esque build process to build it, apply patches, etc, which might be great for prolific package maintainers, but make things a bit more daunting for the new / causal user that just wants to create a simple package.

> how to install two conflicting versions of the same module for two different > applications (one of which may come from the distribution), but this is not > a problem with dpkg or RPM, this is a problem with Python's module lookup > mechanism

Regardless it is an issue that exists. The parent post was saying that "apt should be good enough for all use-cases" which I was rebutting. I wasn't claiming that APT was sucky / broken, but that it doesn't handle all Python use-cases well. Whether it is the fault of APT or Python as to why they might be incompatible in a specific use-case is sort of irrelevant if you end up needing account for said use-case.

> For C libraries there are already good protocols for handling this issue (a > little different for RPM and dpkg).

I'm not fully versed in the mechanisms in C, but IIRC, isn't that why packages are renamed when breaking changes happen over major versions (e.g. libxml vs. libxml2 / libgtk2 vs. libgtk3)? "Rename the package" seems more like a work- around than a system to handle the issue at hand. You're not saying, "I want libgtk with version 3.x".

<comment><USER48> >> Uhm... I don't know why you have a problem with building your own package with the newer version. I do it all the time, for software both others' and mine.

> Maybe things have improved in the past few years, but last time that I built > a dpkg for a Python library it was far from painless

"Past few Debian releases", since debhelper 7.x, not "years" (well, this incidentally matches, too). Debhelper can build properly Python using _setup.py_ and doesn't require anything special (no need to specify any paths) to put artifacts where they can be found by /usr/bin/python. It's actually easier than building analogous C code, since you don't even specify where to put what.

> [libxml vs. libxml2 / libgtk2 vs. libgtk3] "Rename the package" seems more > like a work-around than a system to handle the issue at hand. You're not > saying, "I want libgtk with version 3.x".

For DEBs, yes, this is the case, but you can have several RPMs with the same name but different version.

On the other hand, working with the OS is much easier when the packages differ in their name, so this "workaround" is much more pleasant to use, even though it's not a "pure" solution.</comment></comment></comment></comment></comment>


Mercedes to introduce Siri in its vehicles - <AUTHOR> http://www.psfk.com/2012/02/mercedes-benz-siri.html

<comment><USER2> First reaction upon reading that title: "That's AWESOME!" Seriously, I feel like I am living in the future. Combine that with the self driving cars in Nevada:

"Siri. Take me to the nearest donut shop."

"Yes Zack, right away, Sir."

And the car just drives off by itself, taking me to the nearest pastry haven.

<comment><USER3> I'm not trying to bang a wrong tune here, but in reality - what is the difference between telling Siri "take me to nearest donuts shop" and telling the same to the taxi driver? In the latter, I most likely will enjoy the conversation with crazy taxi driver. Or I can drive myself based on my knowledge or GPS and having pleasure from driving a car. Or again take a cab if Im drunk or too tired to drive. I just don't find the "awesomeness" here.

Besides; although I am not the type of a "kill internet to safe libraries" guy, same time we all know where this is going, right? 3.5 million truck- drivers in US alone [1] plus quarter of million limo/taxi in US (as of 2000) [2], most likely another 10 million in driving-related jobs, all gone within a reasonable period of time needed to implement self-driving cars (year, two?). Hmmm... just wondering - where all this people will go to work?! Thank God, at least in the US alone we maintain a healthy 1% of unemployment rate... oh no, wait!

[1] <http://www.truckinfo.net/trucking/stats.htm> [2] <http://www.schallerconsult.com/taxi/taxidriver.pdf> \- page 3.

<comment><USER4> Everything is give and take. Having self-driving cars would be an absolute godsend for the environmental impact of automobiles. Automated driving can easily be made more fuel-efficient than human drivers (especially when/if most cars are automated and can coordinate traffic plans), and would also open up much more radical car-sharing plans to minimize the number of cars on the road. Transportation might not be the biggest producer of CO2 emissions, but it's a pretty hearty slice, and unless we do something quickly our planet's pretty screwed.

I agree that creating technology for the sake of technology isn't necessarily good, especially if there are negative ramifications in other areas (like job security). But this isn't a black and white "automated cars give us no tangible benefit other than cool factor" situation.

<comment><USER3> Sure, let me send check to Al Gore.

So far I haven't seen any reliable research that would reasonably explain how self driving cars navigated by central algorithms would help to unclog the streets. I for once would be upset if my car decided to put additional 15 miles to get me to work or wherever I want to go just "for a sake of common good of all other automobiles and streets being unclogged".

Henry Ford II: Walter, how are you going to get those robots to pay your union dues?

Walter Reuther: Henry, how are you going to get them to buy your cars?

<comment><USER5> Many of the factors affecting traffic jams are a result of human drivers. This animation demonstrates two causes of traffic jams - 'waves' and zip merging:

<http://trafficwaves.org/tanim.html>

I think it is rather easy to see how a central algorithm would be much better at a) maintaining a safe distance from the car in front, and b) merging quickly and fairly.

Route selection is just one of the things an algorithm could do.

Traffic, by Tom Vanderbilt, has many interesting things to say on the subject: [http://www.amazon.com/Traffic-Drive-What-Says- About/dp/03072...](http://www.amazon.com/Traffic-Drive-What-Says- About/dp/0307264785)

<comment><USER6> Also, the 'safe distance from the car in front' could be dramatically decreased. Reaction times of computers are way lower than those of humans, and also less variable. A car could signal that it is going to brake to a car following it with a meter of space between them, and brake a ms later, trusting the following car to do follow its speed decrease.

Lower inter-car distance on highways will also mean lower air resistance, and hence, higher mpg.

I doubt that the net effect on fuel consumption will be substantial, though. Chances are that people will want their driverless cars to drive faster, so that they can live farther away from work. IMO, the only thing that will help there is pricing (fuel, road use, etc)

</comment></comment></comment></comment></comment></comment><comment><USER7> Good. I'm still not convinced of the utility of Siri to a person walking down the street- perhaps I'm alone, but I don't want to talk to my phone. I find typing to be less conspicuous and not significantly more difficult.

In a car, however, things are different. I think Siri would be a great fit in a hands-free environment.

<comment><USER8> I agree that it is a little strange to be talking to your phone as you walk down the street, but in other cases it is really useful. Siri's voice recognition is so good that many times it is faster than the alternative. It's much easier to say "Remind me to call John at 3pm" and have Siri automatically create the reminder and alarm than it is to go through the steps to manually add the item to your calendar.

As this technology becomes more and more prevalent the social acceptance of it may go up as well. Not sure if that is a good or bad thing though — instead of having millions of people walking around looking at their phone and typing, we'd have millions walking around barking orders into it.

</comment></comment><comment><USER9> My older BMW had voice commands and it was terrible.

My new Audi has voice commands that get sent to Google to be parsed back into commands. It works really well for address book and navigation.

It's not Siri, but it's pretty close. I can't say "remind me in 10 minutes to do X" but I can say "Online Destination ... [ pause ] ... In and Out Burger" and it'll find me the directions to the nearest In and Out.

</comment><comment><USER10> Does anyone see the source of information? I assume this article is not original reporting.

I followed the link to Mercedes' site, and I didn't find "siri" or "apple" anywhere on the page. I can't watch the video right now, though.

<comment><USER11> That was my first thought, too. Google News search for Siri and Mercedes turns up a couple of sites reporting this, and I found the original press release here:

[http://www.daimler.com/dccom/0-5-658451-1-1464474-1-0-0-0-0-...](http://www.daimler.com/dccom/0-5-658451-1-1464474-1-0-0-0-0-0-9293-0-0-0-0-0-0-0-0.html)

</comment></comment><comment><USER12> Necessary. Here's the pathetic voice assistant they used to use on the S-Class : <http://www.youtube.com/watch?v=bateVoomrTY>

</comment><comment><USER13> I've only skimmed the article, but it looks like they're not actually integrating Siri so much as introducing an easy way to interface an iPhone 4S with the car.

</comment><comment><USER14> Using Siri in the car is it's best use case.

I use her daily to send text messages when driving (have iPhone docked on air conditioning vent). Also to get directions and to phone local businesses.

Though outside of driving I rarely use the function.

</comment><comment><USER15> I don't mean to flame Siri (or maybe I do?), but am I the only person who thought, "Uh-oh... get ready for lots of lost Mercedes drivers"?

Listen... I appreciate the concept of Siri, but the implementation still has much to be desired. The other day my wife and I were driving down the road searching for somewhere to eat, and I asked Siri for a Chinese Buffet. Her only response was "Are you looking for Chinese food or a Buffet?" As someone with a hankering for all-I-could-eat, lukewarm General Tso's Chicken, that answer was simply unacceptable.

</comment><comment><USER16> Does this mean the Benz's in-car computer will run OS X?

<comment><USER5> I wouldn't be surprised if this was some kind of web service, rather than running fully within the car.

<comment><USER8> "The program, called the Drive Kit Plus will work in conjunction with Mercedes-Benz' Digital DriveStyle App to translate the iPhone's screen onto the in-car system screen."

Sounds to me like it is more of a "hook your iPhone into the car" system ... and that basically they are just making it easier for you to use your phone with the car's controls, microphone, speakers, etc.

</comment></comment></comment><comment> why-el This has nothing to do with the car per say. I am surprised the discussion went to "Oh get me to the shop". This is only an interface to take to iPhone apps.

</comment><comment><USER17> Is there a developer API for Siri? I was not aware that one had been released.

<comment><USER18> My best guess is that it is using the Siri keyboard speed-to-text feature and the app just does its own interpretation on the text?

</comment></comment><comment><USER19> The first thought I have is the echo of Steve Jobs, cursing Google for getting into the smartphone business. The whole "We did not enter the search business" quote in particular comes to mind.

We're seeing Android@Home and in the car and I wondered where Apple was going to slide in. And here it is. Make no mistake – _going to the high-end car and then slowly make available to the general public_ is a smart, but classic Apple approach. This is where Apple creeps in without really announcing anything specific.

I don't know if Apple acknowledged this, but this method is a way to get into a market (smartcar) without the pitchforks and conversations about who did what first.

<comment><USER19> I'm not exactly sure why I was down voted. I am open to criticism, but I don't see anything overtly negative nor misleading. If you don't agree, please state why.</comment></comment>


VMware Fusion 4 Released - <AUTHOR> http://www.vmware.com/products/fusion/overview.html

<comment><USER2> They seems to change the EULA to allow installing on as may Macs as long as you own it[1], compared to previous license[2]:

        You are prohibited from installing and using the Software on more than one computer at a time

[1]: <http://twitter.com/#!/VMwareFusion/status/113994645062684672>

[2]: <http://www.vmware.com/download/eula/fusion3.html>

<comment><USER2> Can't edit my comment for some reason, but EULA now reads (from VMware Fusion 4 installation):

        VMware Fusion

        You may install and use the Software for personal, non-commercial use
        on any Apple-branded products running Mac OS X ("Mac Computer") that
        you own or control.

</comment></comment><comment><USER3> Did they discontinue academic pricing? Anyway, Coupon: "FUSION20" gives you a 20% discount.

<comment><USER4> Looks like they have academic pricing, but it's the same as the promo price. $49.99: <http://www.vmware.com/vmwarestore/academicstore.html>

</comment></comment><comment><AUTHOR> Release notes

[https://www.vmware.com/support/fusion4/doc/releasenotes_fusi...](https://www.vmware.com/support/fusion4/doc/releasenotes_fusion_401.html)

It runs Windows 8.

<http://twitter.com/#!/VMwareFusion/status/113988639339450368>

<comment><USER5> _Mac OS X Lion and Mac OS X Lion Server are now supported as guest operating systems. Mac OS X Lion can be installed by dragging the Lion installer icon to the virtual machine wizard._

Nice! So, how exactly does one do this? The Lion Installer seems to be gone from my system since I upgraded to Lion...

<comment><USER6> Re-download Lion from the Mac App Store. You'll find it under the "Purchases" section. Everything in that section can be re-downloaded and reinstalled for free.

</comment></comment></comment><comment><USER7> VMWare Fusion 3 customers, no need to fret. Unless you purchased after July 20th, you get to pay full price just like everyone else. ( I'd be happy to be wrong, but at this point, I feel a tad betrayed. To the point that I am considering dumping Fusion )

<comment><USER2> $49 full price isn't that bad compared to Parallels 7. Not only you have to pay $49 for an _upgrade_ , it will also slow down your boot time drastically[1]. VMware Fusion user can get P7 for $29[2] but from my experience I'd rather not switch.

I upgrade to P7 few days ago, and today I'm switching to Fusion 4 hope to never become Parallel's customer again. (Unrelated note, it took Parallels 7 hours to send me an upgrade key after purchase while it only took VMware 3 hours to _answer_ my question regarding Fusion 4.)

[1]: <http://forum.parallels.com/showthread.php?t=113543>

[2]: <http://www.parallels.com/products/desktop/vmwareoffer/>

<comment><USER8> On my account page, license section, they've put this notice:

"Upgrades for the following products: View 5, _Fusion 4_ , Workstation 8, Site Recovery Manager 5, and vFabric will be available on the licensing portal by the week of 9/19. If you have questions, please contact License support."

So maybe upgrade prices will be available next week.

<comment><USER7> Thank You!

</comment></comment></comment></comment><comment><USER9> Does anyone know if this supports the the vmwgfx Gallium3D driver for accelerated opengl in linux guests?

UPDATE: VMware responded (within 6 minutes) on Twitter and the answer is no. [https://twitter.com/#!/vmwarefusion/status/11402734522400768...](https://twitter.com/#!/vmwarefusion/status/114027345224007681)

</comment><comment><USER10> As a new Mac convert, why would one use this, instead of VirtualBox?

<comment><USER11> Fusion and Parallels both are a bit faster than VirtualBox and have more features.

Also, VMWare VMs will work with any VMWare product so if you are working with a team that uses VMWare elsewhere its nice to have.

If you are just trying to run a Windows app or two you are probably better off with VirtualBox since its free.

<comment><USER12> Except for OSX VMs built using Fusion's built-in capabilities. The other VMware products don't ship the required libraries to boot them.

<comment><USER13> You have to downgrade the vmx to prep a fusion vm to be loaded into esx. Or you can download the vmware convertor app that will transfer the vm, convert the vmx, and register the vm in esx.

I use the application weekly for this task.

<comment><USER12> I meant OSX as a guest OS.

<comment><USER13> For that you'll need a machine with SMC and only Macs have it.

</comment></comment></comment></comment></comment></comment><comment><USER14> Free update for those who bought Fusion 3 after the release of Lion! [1]. No word on pricing for old clients as of yet.

[1]: [https://twitter.com/#!/VMwareFusion/status/11410952248165990...](https://twitter.com/#!/VMwareFusion/status/114109522481659904)

</comment><comment><USER15> What happen with DirectX 11?

"The WDDM driver for Windows 7 and Vista now includes support for DirectX 9.0EX with Aero and OpenGL 2.1. Windows XP now includes support for DirectX 9.0c and OpenGL 2.1."

</comment><comment><USER16> I've just given it a quick go and gone straight back to v3. Fusion on Lion still lacks native full screen and the interface feels a lot slower. Nevermind, maybe a rush to compete with Parallels?

</comment><comment><USER17> I wish Fusion worked half as well as VMware Workstation does on Windows. OS X's memory management appears to shoulder most of the blame.

Darwin loves to hold on to recently wired memory as long as possible and does not gracefully dump out 2GB of inactive memory at a moments notice. The performance of snapshots as well as multiple VMs even inside 8GB of RAM totally sucks compared to workstation.

</comment><comment><USER18> Still no 3D support on linux, and I don't see any mention of pause/resume support for Boot Camp partitions. Disappointing. Parallels has had both of these for a while.

Useful (but not updated for 4): [http://en.wikipedia.org/wiki/Comparison_of_VMware_Fusion_and...](http://en.wikipedia.org/wiki/Comparison_of_VMware_Fusion_and_Parallels_Desktop)

<comment><USER19> There's a good reason why you can't. If you suspend Boot Camp in VMware and then try and reboot into it it could cause corruption of your Boot Camp partition. If you really want to do it though I seem to remember reading about a plist tweak that adds the options back in.

Edit: <http://communities.vmware.com/thread/108022>

</comment></comment><comment><USER20> VMware Fusion 4 has a migration utility to upgrade from 3, really nice

<http://twitpic.com/6kwhhs>

</comment><comment><USER21> I tried out P7 when it was released, and immediately migrated back to Fusion 4 today when it came out.

</comment><comment><USER22> I don't even get how people can use VMware. I've tried it on my macbook and it's unbearably slow. I bought a cheap PC off of craigslist because VMware was too slow to use. 4 gigs of ram and still lagged like all hell.

<comment><USER19> I found my 2010 MacBook Pro with 4Gb unbearably slow even without running VMware Fusion. Mac OS X really requires 8Gb these days, unless you're running an SSD.</comment></comment>


Coursera Secures $43M in Series B Funding, Plans to Double in Size - <AUTHOR> http://blog.coursera.org/post/55080731561/coursera-secures-43m-in-series-b-funding-plans-to

<comment><USER2> Really good news for coursera. I hope they raise the bar when it comes to online education - it's about time!

Too bad they are not considering remote applicants at the moment :(</comment>


Myth-busting article about radiation hardened microchips for space applications - <AUTHOR> https://habr.com/en/post/518366/ <comment><USER2> I don't understand the need to editorialize by changing the title. If you read the title posted here, you may get the impression that there's no need for radiation hardened chips can be used. It would be better to use the actual title "Common misconceptions about space-grade integrated circuits".

To me the actual title more properly reflects a good summation of the article:

"The ultimate answer to a question if COTS chips can be used in space is "Yes, but". There are many opportunities, but also many constraints."

<comment><AUTHOR> Your point is very valid, in retrospect I think that I shouldn't have changed the title.

</comment></comment><comment><USER3> > Just like anyone else, they normally write code filled with crutches to be > ready for yesterday's deadline and want more powerful hardware to mask their > sloppy job; some would've used Arduino if it was properly certified.

The (very interesting) main thrust of the article aside, I see this kind of sentiment a lot and I don't really understand it. Arduino's just a common dev board, running a standard microcontroller, plus some hand-holding libraries (which you can dispense with if you want.) Is there any actual legitimate reason that they're not suitable for production use? Or is it really just "real-embedded-devs-don't-use-Arduino" ego flexing?

<comment><USER4> I don't understand it either.

The main part of Arduino is the hardware abstraction library. Especially for the standard stuff, like iwc, spi, ... this hal makes your code portable between different microcontrollers!

The alternative to Arduino hal is to use the vendor libraries. By doing that, you lock yourself in to the specific controller you are using right now. Also, the quality of the official sdks often enough is joke.

The next thing is the library ecosystem. A device driver library, i.e. to use a certain sensor, from the Arduino evosystem will work on every microcontroller with Arduino support, which is a very very long list.

The arguments against Arduino?

It's not _professional_.

Yeah, try the vendor library, sdk and ide and tell me that's better ...

You are relying on code that _somr guy in the internet_ wrote.

Jup. That's how the whole industry works. If your are using windows, you are using code some guy at the internet wrote. Did you ever get recourse from MS after you got a BSOD? Relying on code from other people is how we are able to get anything done. If you wrote everything from scratch, you couldn't ever ship anything. And hey, you got that code from that guy on the internet for free. So do the world and yourself a favour, review the code and upstream any improvements you find!

The IDE sucks.

So does the vendor IDE and nobody is using that stuff anyway. Use platformio.org

There is many situations where Arduino is a valid option.

<comment><USER5> Honestly I think in the embedded world HALs are a problem with how diverse the micro controller area is getting - especially heterogeneous multi-core chips. HALs end up targeting the least common denominator but there may be a really good reason why you would want a particular micro controller in the first place.

I think Andrei Alexandrescu has a good idea that he presented in his talk about compile time introspection^[1]. That combined with something like ARMs SVD, but vastly expanded to include practically all hardware resources, might be the future. That way you could use exactly what you need.

Of course the embedded world changes very slowly, so if this every does happen I'll be long retired...

^[1] [https://www.youtube.com/watch?v=tcyb1lpEHm0](https://www.youtube.com/watch?v=tcyb1lpEHm0)

</comment></comment></comment><comment><USER6> This is a good article. It covers all the facets of radiation hardening pretty well.

I worked on a radiation hardened processor chipset that had to be very rad hard - total dose, prompt dose, SEU all had to be addressed. That required measures be taken at the process, physical layout and architecture levels while making it performant and low power. Conclusion: very difficult, but possible, and some very interesting problems to solve (like how to mitigate the effects of an SEU in the instruction register at the moment of execution).

I also was peripherally involved with testing COTS memory chips for radiation hardness. They only had a modest total dose requirement. That was messy for the reasons mentioned in the article, like the fact that the manufacturers are always tweaking process and design parameters to optimize for the commercial DRAM market. So from one lot to the next the radiation hardness was unpredictable. Conclusion: costly, time consuming and not sustainable.

</comment><comment><USER7> Some wrinkles in the article, it looks like it was well-translated from the original, but figure 7 is explained "on the right" twice; one instance should say "on the left", and figure 8 is missing entirely.

I wonder if the FDSOI back-charge technique could be cycled to provide periods of immunity, then "dump" the stored charge (while holding the chip in reset), then become immune again..

Fascinating stuff! Mostly over my head! Literally! :)

<comment><AUTHOR> I'll fix it, thanks. The problem occurred because it was not translated, but more "rewritten", and this particular figure was changed. Regarding actual question, that wouldn't work unfortunately. "Dumping" isn't possible as effects are complex and nonlinear. Maximizing total dose hardness via back gate voltage would require complex voltage control. But there could be something, for example, if one tries to use accelerated high-temperature annealing.

</comment></comment><comment><USER8> Fun fact, the still persistent use of "rad" instead of Gray (RoW) unit seems to stem from the US NIST confusing radians with rads and saying rad is an SI- conformant unit (which it never was).

</comment><comment><USER9> Bear in mind that it's a Russian site and they have a huge problem with producing or buying radiation-hardened chips. So it's kinda 'sour grapes' attitude.

<comment><AUTHOR> It's not "huge" problems. Russian state of art radhard design is mostly on par with what exists in Europe and just a couple of generations behind the USA. Most of production is obviously abroad, and nobody actually cares, as it involves much less money than Huawei case)

Also, this site was chosen for publishing because it was easy and because they actually give you some audience. Getting the same attention at Medium would be much harder, and a copy of this text, which I posted at LinkedIn, got something like 60 views. LinkedIn has a great publication editor, by the way. If you have an advice on some better place where I could publish scipop texts about microchips, that would be really appreciated.

<comment><USER9> If they really were 'on par' then you won't have issues with your satellites.

<comment><AUTHOR> This "you" doesn't apply to me as I don't live in Russia.

The problems with satellites are mostly due to competely different factors, not the state of radhard IC design. For example, transition from imported to domestic EEE components is painful, as the demand is much higher than industry's capacity.

<comment><USER10> If I remember right. The north americans made a lot of noise when SpaceX managed to take Nasa people to space, because USA was relying on Russian space program, lol. So I think they are on par

</comment></comment></comment></comment></comment><comment><USER11> The knowledge required to understand the vocabulary used in this article seems to disqualify anyone who might have such misconceptions to actually read it to the end.

<comment><AUTHOR> Oh, I've seen examples of these from the people who managed to work in space industry for decades. Also, I hoped that I gave enough terms and definitions in the beginning( I would appreciate any feedback on what could make the text better and more understandable for wider audience.

</comment></comment><comment><USER12> > all the fuss with lead-free solder was partially caused by the fact that > lead and some other materials used in IC fabrication contain impurities of > heavy elements like uranium.

This is complete news to me.

Lead free solder was mandated by the European Union's "Regulation of Hazardous Substances" legislation, whch was drawn up by a bunch of ninnies with no understanding of biochemistry, nor mathematics, nor epidemiology.

Electronic devices are _more_ reliable with tin-lead solder rather than Aluminum based solders.

<comment><USER13> Um, isn't one of the benefits, especially for hobbyists, that you're not inhaling lead-laced fumes?

<comment><USER14> Not at the temperatures hobbyists are soldering at. It's more of a concern for industrial soldering.

Hobbyists have to worry about the fumes from flux instead, and lead free solder requires more flux.

<comment><USER15> I don't really get this. Surely the problem is you're handling lead in a home context? That's never going to be safe, since unless you're very careful about cleanup, you're going to get lead in your food.

To me, all this talk about lead being so much better feels a bit silly. As a craftsman, I can see that lead is nicer to work with, and makes for more pretty results. As a dad, I'm pretty glad that every electronic object isn't laced with lead - in fact, I'm glad about every measure full stop that reduces the industrial usage of lead. One of these things is way more important to me than the other.

<comment><USER8> I don't understand what you're saying. Using hand soldering tools, the tin- lead alloy becomes a liquid, sure there might be traces of lead going into the air that you can _detect_ (ppt? ppq?), but that doesn't make it a health hazard. You might abrade traces of lead onto your hands handling soldering wire, but surely washing your hands after soldering gets rid of that. If you do a few mistakes you might get small lead balls in your work area, but even then I don't see how it gets in my food. I don't understand why solid lead or alloyed lead is supposed to be a safety problem by itself. It's not radioactive, you don't get sick by standing next to it, you have to abrade it and eat the shavings.

Heating soldering wire isn't creating lead vapors like leaded gasoline does.

<comment><USER15> Lead is soft - you're definitely leaving traces of lead on your hands when you handle it. That then goes onto your clothes, your skin, and everything you touch.

But anyway - it's not really the point. The point is, I can confidently say that some idiot burning a trash bin isn't going to scatter lead all over the local enivroment - ditto a house fire, or a car crash, or somebody dumping a computer in a stream.

</comment></comment></comment></comment></comment></comment><comment><USER16> There are many different radiation environments in space, which a quick skim of this article seems to ignore entirely. Low earth orbit isn't that high-rad because of the earth's magnetic field. Go outside outside it and you need some rad hardening for sure. Orbit in the van allen belts or go somewhere like Jupiter and you need extensive rad hardening for sure.

<comment><USER17> You might just want to read the section called "Different orbits and other applications of radhard ICs".</comment></comment>


React 0.14 Release Candidate - <AUTHOR> http://facebook.github.io/react/blog/2015/09/10/react-v0.14-rc1.html <comment><USER2> Functions are components! Yay! Here's the quote:

 _In idiomatic React code, most of the components you write will be stateless, simply composing other components. We're introducing a new, simpler syntax for these components where you can take props as an argument and return the element you want to render:_

        // Using an ES2015 (ES6) arrow function:
        var Aquarium = (props) => {
          return <Tank>{getFish(props.species)}</Tank>;
        };

        // Or with destructuring and an implicit return, simply:
        var Aquarium = ({species}) => (
          <Tank>{getFish(species)}</Tank>
        );

        // Then use: <Aquarium species="rainbowfish" />

<comment><USER3> So in other words, Reagent? [https://reagent- project.github.io/](https://reagent-project.github.io/)

<comment><USER4> There are always going to be similar ideas across different languages, frameworks, and platforms. Your comment implies... some sort of equivalence between React's announcement and Reagent? I'm not sure. Maybe you're saying "this has already been done before." If that was indeed your point, it would be more constructive to point out that here is an existing library with similar ideas that might prove useful to React developers.

</comment></comment></comment><comment><USER5> I'm very excited about:

        React.Children.map now returns plain arrays too

Before this change, we would have to do the following when checking the types of children components (in propType validation):

        const childrenTypes = [];
        React.Children.forEach(props.children, child => {
          childrenTypes.push(child.type);
        });
        for (const type of childrenTypes) {
          if (type !== MyComponent) {
            return new Error(`Child '${type}' is not an instance MyComponent. Check render method of 'ParentComponent'.`);
          }
        }

It sort of made sense that map() on an opaque data structure would return the same type of data structure but in practice this was rarely useful.

Thanks, React team!

<comment><USER6> This also helps with Typescript that required

      var products:Array<Product> = []
        for (var x in this.props.products) {
          products.push(this.props.products[x])
        }

</comment></comment><comment><USER7> Stateless function components are definitely super exciting (we had been faking this with just Component(function() { return .. }). I'm interested how it handles shouldComponentUpdate though. We do some interesting things in there to deal with cursors, etc, so it would be nice to be able to get into the standard shouldComponentUpdate.

<comment><USER8> Yes. The function components are awesome.

I use Redux, where all the state tickles down through the props, so I can probably remove a huge chunk of boilerplate in my apps.

<comment><USER9> "I use Redux, where all the state tickles down through the props" Isn't that just flux, or even just good React practice?

<comment><USER10> It's good React practice, but it's not really Flux. A lot of Flux/Flux- inspired frameworks have components actively listen to global stores.

</comment></comment></comment></comment><comment><USER11> I'm very excited about this release!

Question for other React devs out there: how long would you typically expect it to be before we can start migrating over?

Will older React components designed for 0.13 still work if they don't include the react-dom package?

<comment><AUTHOR> Yes, they'll work with a warning until 0.15.

<comment><USER11> You guys are the best :)

</comment></comment></comment><comment><USER12> Great work from the React team. I know the answer to my question is "when it's ready" but any thoughts as to when React might go 1.0.0? I've played around with it and like React a lot but I don't want to deploy until it's "version" stable. Happy to hear time (2016 summer) or version (after 0.20.0) estimates.

<comment><AUTHOR> For a while, we were aiming for a "1.0" release. Lately, we've been more of the opinion that React will probably continue to evolve over time. We'll probably skip over the dot sometime (e.g., 0.14 -> 15.0) to help reflect that we do recognize these current versions as more or less stable.

The other opportunity is to just call some version 1.0 and then wait some amount of time (a year? two? five?) before making any breaking changes, which sounds less appealing to us. You can always continue to use an older version (and we'll backport serious fixes like we did in [http://facebook.github.io/react/blog/2013/12/18/react-v0.5.2...](http://facebook.github.io/react/blog/2013/12/18/react-v0.5.2-v0.4.2.html)) but we plan to continue developing React and hope that people will continue upgrading to new versions.

If you're concerned about whether it's production-ready (as opposed to future API changes), the answer is definitely yes.

<comment><USER12> Thanks for responding. I'm happily using React in my personal life but we don't use it at work (for no reason than we don't need SPA). One last question, is there an official policy as to how long will you support a release?

</comment></comment></comment><comment><USER10> > React uses console.error instead of console.warn for warnings so that > browsers show a full stack trace in the console. (Our warnings appear when > you use patterns that will break in future releases and for code that is > likely to behave unexpectedly, so we do consider our warnings to be "must- > fix" errors.)

Out of all the release notes this is probably the one that I'm the most excited about. Hopefully this sheds some light on the more confusing warnings (e.g. warnings about missing keys with no real way to determine _where_ they are missing).

<comment><USER13> Another way, which we actually supported in 0.13, was to turn on "pause on caught exceptions" in your debugger. We throw and catch a warning so that you could catch warnings live. We continue to do that now, just with the added benefit of having the stack trace showing up without needing to pause.

</comment></comment><comment><USER14> I really appreciate the focus on adding more helpful warnings to help inform you when you're unknowingly about to shoot yourself in the foot.

</comment><comment><USER15> What does react use typescript and coffescript for? they are listed as a dep in package.json

<comment><AUTHOR> We just test that their class systems work properly with React:

[https://github.com/facebook/react/tree/v0.14.0-rc1/src/isomo...](https://github.com/facebook/react/tree/v0.14.0-rc1/src/isomorphic/modern/class/__tests__)

We don't use either one outside of the tests.

<comment><USER16> I think that means you can move them to the `devDependencies`.

edit: Derp, they're there already

<comment><AUTHOR> They already are in devDependencies.

</comment></comment></comment></comment><comment><USER17> >React now supports two compiler optimizations that can be enabled in Babel 5.8.23 and newer. Both of these transforms should be enabled only in production (

Am I missing something about how you tell Babel to enable/disable these?

<comment><AUTHOR> Enable them like you would enable or disable any other babel transformer, using the "optional" param in .babelrc (or --optional on the command line, etc).

</comment></comment><comment><USER18> Looks like we're almost to the point where we can say "universal" instead of "isomorphic".

Awesome.

<comment><USER10> I prefer "unimorphic" or "isoversal" at this point.

"Universal" has its own share of problems. I'm not sure switching from one wrong and confusing term to another is worth the effort.

</comment></comment><comment><USER19> This versioning is pure crap.

<comment><AUTHOR> Can you help us understand why?

<comment><USER20> I speculate that it's because it's not treated like a Real number, where values increase like [0.1, 0.2, 0.25, 0.27, 0.29, 0.30].

React 0.14 supercedes 0.13 but it is not superceded by 0.9.

<comment><USER21> 14 > 13 > 9

"Math is pure crap"?

<comment><USER22> Well, fwiw, 0.9 > 0.14 > 0.13. Guess it depends on how you look at it.

<comment><USER21> The "." in versions is not a decimal point. There's certainly no such number as 0.9.1.

<comment><USER22> I know. Which is why I said that it depends on how you look at it.</comment></comment></comment></comment></comment></comment></comment>


Show HN: I built a database of tech conferences to know what to attend to next - <AUTHOR> https://conferencelist.co <comment><USER2> Well done! this is one of the best "Show HN" posts I've seen. Solving a simple & actual problem, and not needing to specify what language or framework you used as justification for it. I really wish more posts were like this.

I wish I could click a keyword in a conference list and then see more conferences with that keyword.

Also, the top date menu is confusing for me. I actually thought for a while the 18 was for Day of month, not year. But at least year makes more sense than some ranges that would end mid-month.

I tinkered and came up with two alternatives (I like the bottom one more) [http://i.imgur.com/P0sz1aA.png](http://i.imgur.com/P0sz1aA.png)

Keep up the great work!

<comment><AUTHOR> Thanks a lot! Tags will be clickable soon & will review the top menu to make it clearer. Thanks for your feedback, appreciated!

<comment><USER3> +1 on the execution

+1 to the request for the clickable tags - as that was the first ting I tried to do.

Good job. The only suggestion I can think of right now would be to add a link to the linkedin group surrounding that conf.

</comment></comment></comment><comment><USER4> I've seen event aggregators come and go. Usually they die off when the maintainer gets bored of the events. Anything different planned here?

<comment><AUTHOR> I promise to not get bored and to add more value to it soon;) Or to find a way to automate the maintenance while adding more value :)

<comment><USER5> You could add...

A calendar with a tag cloud that can be toggled.

A world map with the same tag cloud.

Work backwards and make it into an archive of-

a conference about conferences.

<comment><AUTHOR> Haha a conference of about conferences is def. not in my mind. But everything else you suggested, it is! Thanks!

<comment><USER5> I was joking but after thinking about it the Meta Conference might attract a small but fascinating audience. I doubt it would be boring. Organizing it is probably the easiest conference ever organized. You just ask for help along with the invitations.

It's such a dumb idea it <s>might</s> will actually work.

</comment></comment></comment></comment></comment><comment><USER6> How is this different from [http://lanyrd.com/](http://lanyrd.com/)?

<comment><USER7> Lanyrd is a dead site walking. They were acquired by Eventbrite ~4 years ago, and haven't seen any meaningful updates since May 2014. Their social media accounts have been completely dead for two years. The site has frequent uptime and spam issues, and attempts to reach out to Eventbrite folks are met with complete silence.

And yet, it still exists, running along with juuust enough inertia to crowd out any potential replacements.

If you're reading this and work at Eventbrite: Please, lobby internally to put Lanyrd out of its misery.

<comment><USER8> I can't say much on the subject, at least not without official approval, but understand that the original Lanyrd team have not forgotten about the site; asking us to fix it isn't really giving us any new information (sadly).

If you want to make requests of any kind you're better off reaching out to Eventbrite directly.

<comment><USER9> Interestingly, IIRC there were only 2 people involved in the creation of the site, maybe even up to the time of the acquisition.

It's a shame it's been left to languish.

Seems like this should be a feature of papercall.io which seemingly has a more obvious path to sustainable revenue.

</comment></comment></comment></comment><comment><USER10> If you're looking for additional sources of events, you could try adding the events from [http://techmeme.com/](http://techmeme.com/). They have a sidebar which is always current. They also have: [http://www.techmeme.com/events](http://www.techmeme.com/events) which would add a lot of flow.

</comment><comment><USER11> The "Where" filter doesn't seem to work:

Where: Germany "We couldn't find any results. Select other filters, or let us know if we miss a conference."

Where: Cologne, Germany "Pirate Summit - Cologne, GermanySep 6 - 7"

<comment><AUTHOR> Fixed, it was meant to search the exact location, while Keywords would allow a wider search. But you can use Location filter to do this as well, now.

<comment><USER12> hmm still won't work. I type in germany/ Cologne / Deutschland in Location and can't see the Pirate Summit one. If I type in Cologne, Germany I can see all entries ;)

</comment></comment></comment><comment><USER13> This will sound like a strange suggestion, but think about collecting people's emails and sending out an email every quoter or so with a list of conferences. Of all the newsletters I wouldn't mind this one at all.

<comment><AUTHOR> It isn't :) It is basically a must do before any launch, but I did not expect so much interest to be honest so I only focused on the core functionality first.

</comment></comment><comment><USER14> Just some design thoughts that you could consider:

I think you could better separate the actionable filter items from the branding parts. So, in a thin top tier, have your brand top left, "Find conferences near you" in the middle, and perhaps "Add a conference" top right. This will give you more room to fit conferences on screen - at the moment it's a bit sparse - 500px before I get to the listing itself.

Then you can have the filters and search boxes in their own area and have more room to make it really obvious that their use impacts the list below without the line "Know a conference..." in between.

You could consider updating "Upcoming conferences" with info pertaining to the search. e.g., "Conferences in Jul-Sep 2018".

I can appreciate that "18" alone saves space, but my first thought was that it was September 18th. You could use 2018 or '18 maybe?

Put a max width on the conference icons and a margin on the right - the widest ones are butting up against their names.

<comment><USER15> While on the design topic. Use PNG instead of JPG for logos. They all bleed artifacts badly right now.

</comment></comment><comment><USER16> Pretty cool! Still a lot of work on missing conferences, but hopefully that can self-correct if it becomes popular and organizers submit their conferences.

Most security conferences are missing. Black Hat, bssides (except canberra, apparently), defcon, toorcon, recon, usenix, chaos computer club congress, RSA.

</comment><comment><USER17> While technically not a conference, you're missing a big one: SHA2017 in The Netherlands [1]. Starts the 4th of August, and there are still some tickets left.

[1] [https://wiki.sha2017.org/w/Main_Page](https://wiki.sha2017.org/w/Main_Page)

<comment><AUTHOR> Will add it. And will make sure to load the one from next year, once that one will be announced :)

</comment></comment><comment><USER18> I did something similar (as an SEO gambit). Filterable by country (click the map). Feel free to take my data!

[https://codefor.cash/startup-developer-tech- conferences-2017...](https://codefor.cash/startup-developer-tech- conferences-2017.php)

</comment><comment><USER19> Nice idea, but buggy implementation: if I search for "Germany" nothing shows up. If I type "Berlin, Germany" (an event show up).

You might want to fix this.

<comment><AUTHOR> Yep. Keyword search is meant to tags only. I will extend it to search in everything tomorrow.

<comment><AUTHOR> Fixed!

</comment></comment></comment><comment><USER20> DataFox also has a solution for indexing valuable conferences that syncs with your Salesforce. [https://www.youtube.com/watch?v=Zq5uauwm4TU&t=0s](https://www.youtube.com/watch?v=Zq5uauwm4TU&t=0s)

<comment><USER21> Would like to second DataFox as a valuable tool for identifying conferences that our Salesforce prospects are attending.

</comment></comment><comment><USER22> When I type in a city to the "Where" box and hit enter, it flashes quick but doesn't seem to filter.

Also whenever I type anything into the "Keyword" box nothing is returned.

<comment><USER23> Looks like they hit the daily request limit on the Google Maps API (you'll see the error message if you hit Cmd-Option-J in Chrome).

<comment><AUTHOR> Indeed! I did not expect so much traffic! I'm working now to restore it.

<comment><AUTHOR> Fixed! Sorry everyone!

<comment><USER24> broken again

</comment></comment></comment></comment></comment><comment><USER25> You should perhaps consider turning this into a paid email list service, that routinely sends out an update on the conference list with a bit more information on each. Charge maybe as low as $5 or as high as $12, per year. A couple thousand subscribers over time and you have yourself a nice side business. If you make it inexpensive enough, people will be happy receiving the updates via email, rather than having to remember to visit your site regularly.

</comment><comment><USER26> Suggestion: Add the conferences talk submission info and deadlines, so you can use it to find out what conferences to talk at.

<comment><USER27> This would be a great feature for me too. I'm looking for conferences I can apply to speak at, and it's often kind of difficult to extract basic info like this from event sites.

It would also be good to see similar info for conferences that have exhibitor booths.

</comment></comment><comment><USER28> Nice idea. The searchability is certainly nice.

For a much more complete listing (although with a somewhat different focus) you can also use the LWN community calendar, which has been around for what feels like forever: [https://lwn.net/Calendar/](https://lwn.net/Calendar/)

</comment><comment><USER29> Notice that the app doesn't really keep a history of state. After executing a search, back arrow on browser doesn't do what the user would expect. Either give a "reset" option, or better, don't break the browser and implement something like pushState()

</comment><comment><USER30> I loved it! Already submited a local conference. Hope you make it to the front page :) You could stick some users if you create some kind of newsletter according to location and/or event tags. If you want some help, I would work on this!

</comment><comment><USER31> Nice work! There is still room for improvements, but this website will certainly provide a lot of value to developers.

As an additional feature, considering the target audience, I would suggest to add some API with filter option, using CalDav format for example [0]. Everyone would be able to fetch latest data from conferencelist in their local calendars ;)

[0]: [https://tools.ietf.org/html/rfc4791](https://tools.ietf.org/html/rfc4791)

<comment><AUTHOR> Thanks & indeed, I plan to add the API soon! Cheers!

</comment></comment><comment><USER32> Nice, a much-needed tool! Suggestion: make it a collaborative effort to keep it updated. In practice, it can be solved rather easily. Host the website on Github Pages. Have a single file in the github repository named e.g. conferences.json which the website reads over AJAX. Anyone can submit pull requests (PR) to add to or modify the conferences.json file, effectively allowing community members to help you maintain the website's freshness.

</comment><comment><USER33> Some things I would like:

\- See fees (including deadlines for each phase ?)

\- Subscribe (by email) to tags (new conferences with a certain tag) and/or ending of Early Bird phase (or other phases)

\- Have rss feed based on tag(s)

\- See similar conferences (based on tags)

\- Button to add a conference to my calendar (or maybe have Google calendar feed, based on tags)

\- Filter by region; I do not mind flying a few hours, meaning anywhere in Europe for me. But I will never go to the US and not easily to Asia.

<comment><AUTHOR> Really good points, thank you. Will add them soon:)

</comment></comment><comment><USER34> You're missing all of the QA conferences!

[http://testingconferences.org/](http://testingconferences.org/)

</comment><comment><USER35> Great idea go for it!

lanyrd.com is long dead without any good replacement. I'm not too sure why they keep the website up. What it does it only confuses people. I know that this probably out of their control right now. Eventbrite killed the really good website.

The service they had was solving real problem. Now you are solving real problem. Good luck!

<comment><AUTHOR> Thanks a lot, all this feedback gives me wings :)

</comment></comment><comment><USER36> Looks nice. I've wanted something like this. It would be better if I can subscribe a search result.

<comment><USER37> [https://www.techconferences.io](https://www.techconferences.io)

Full disclosure - this is my site -- but you can join and keep track of conferences.

<comment><AUTHOR> Haha, good one! Yours is more a database than mine, indeed! :)

</comment></comment></comment><comment><USER38> Ugh. Why is everyone excited about yet another online directory? Is it because it is tech conferences and people here are just jazzed by lists of dorky things they can do besides mow their lawns (sorry, for folks outside SF who actually have lawns), or do their regular maintenance on their car?

This is not a problem that needs a solution. It's yet another developer (or wanna-be 'need a job in development' person) who needs a puff portfolio piece that shows he knows how to connect a few database fields with a front-end display - and mixed with search! Wow! (Well, it mostly works anyway).

I have yet to see one of these ShowHN pieces be anything but the latter. They should split ShowHN into ShowHNFluffYouBuiltToGetAJob and ShowHNStuffThatSavesLives, because I'd only be interested in the second one.

And of course, you have to have your submissions vetted by the guy who not only "promises" to always maintain this (I call), but who obnoxiously floats his Twit handle over the footer as you scroll... he either doesn't believe in crowd-sourcing genuinely or doesn't want to deal with a user-end database. Likely, he'll turn that "I don't charge to be listed" into "listings are only $99/year" pretty quickly.

Whoever said this guy was solving a "simple and actual problem" is sadly misleading this poor fellow. It was not a problem. Conferences are not concerned that there are not enough listing sites out there. Conference attendees are aware of, in their respective circles, where to go and what to attend. It's not a simple problem. It's not a problem at all.

What is a problem is the proliferation (i.e. clutter) of the internet of everyone and their sister building fluffy stuff with .co and .io domains. Can I just block all such domains from my browser? My internet would actually be better if I could.

Sigh... the death of the Yahoo Directory was heading toward this all along, wasn't it?

</comment><comment><USER39> Does this do direct match on location only, or search in a radius? San Francisco only shows things happening in the city proper, no surrounding areas. Could be that's all there is but I'd expect other parts of the bay to show up as well.

<comment><AUTHOR> Direct match on location now, radius next. Plus the database is still in process of being loaded; it's just started, I'm sure I miss tons of conferences for _now_ :)

</comment></comment><comment><USER40> Nice, thank you for this! I would suggest ordering the events by distance from the typed location, instead of filtering with a perfect match.

This way the user only has to type one location instead of trying a bunch of places near him/her.

<comment><AUTHOR> Thanks! That's next, coming in a few days :)

</comment></comment><comment><USER41> AutoSens isn't listed on it.

[http://auto-sens.com/autosens-brussels/](http://auto-sens.com/autosens- brussels/)

</comment><comment><USER10> I am all in favor of side projects but I found a number of disturbing errors:

* There are no conferences for either Ruby or Elixir * There are no conferences on bitcoin * There is only one conference for React * You can leave data in the form on where by not picking autocomplete and then it appears to have searched for it but gives incorrect results * The only way to clear the date settings is to reload the page

I love the concept and the lack of knowing what conferences are happening even nearby is a very real problem but I think there are issues with your database and your search interface.

<comment><USER42> I could add to that, that for Location: Germany and Keyword: Python the page really recommends PyData Delhi (India) while PyCon DE 2017 is upcoming on October, 25th.

Sorry - love the idea. Am disturbed by the subpar execution.

<comment><AUTHOR> PyCon DE was added:)

</comment></comment></comment><comment><USER43> Spingo.com maintains these all and so does predicthq.com.

</comment><comment><USER44> Nice. An ability to filter by price (and actual availability), application / submission deadline, and volunteer opportunity would be useful, also.

<comment><AUTHOR> Thanks for the suggestion, I'll add it!

<comment><USER44> "Hipmunk for conferences." You might be able to make an actual thing out of this.

</comment></comment></comment><comment><USER45> I built something very similar: [http://confir.io/](http://confir.io/)

</comment><comment><USER46> It crashed when i tried submitting a conference with a lot of tags. Where can I submit a bug report?

<comment><AUTHOR> firstname.lastname@example.com

<comment><USER46> Got a reply, fix is in the works! Love it!

</comment></comment></comment><comment><USER47> Excellent page! I suggest adding a filter for continents (where > Europe doesn't work).

</comment><comment><USER48> Another use case for this is finding conferences to speak at. Nicely done!

</comment><comment><USER49> Thanks so much! I've been looking for something like this for Asana.

</comment><comment><USER50> Are you manually entering conferences in your database?

</comment><comment><USER51> Have any of you open sourced your app, by any chance?

</comment><comment><USER52> How about sorting by deadline for submissions?

</comment><comment><USER53> Nothing in Shenzhen.</comment>