Decide how to package Brian2GeNN

[mstimberg]

I think we are ready to publish a first official (beta?) release of Brian2GeNN, it now reasonably well detects unsupported features and it runs non-trivial examples like Kremer et al. (2011).

I wonder what is the best way to package it, though. Brian2GeNN does of course depend on GeNN, but it would not make much sense to specify this dependence on the Python level, since GeNN is not a Python package (we won't upload it to pypi). In principle, we could create a conda package for GeNN, but given that it would not do much except for copying the files, I am not sure it is worth it.

One option I was considering: include the GeNN source code itself into Brian2GeNN via a submodule, and ship it alongside Brian2GeNN in pip/conda packages. I think this would be the most user-friendly option (a simple pip install brian2genn or conda install -c brian-team brian2genn would work), and it would also avoid potential conflicts with future versions of GeNN.

There is one problem with this solution, though: both pip and conda allow the installation of packages system-wide (even though it is uncommon for conda), so GeNN could end up in a location not writeable by users without administrator rights. During the compilation of GeNN projects, some files will be compiled to the source directory, so this would fail. Could we pre-compile these files when we create the conda package (let's not worry too much about pip, this could remain "semi-automatic", i.e. you'd still have to install GeNN independently), or do any of these files have to be re-compiled in a project-dependent way?

[thesamovar]

I love the idea of such a simple installation, although I think it's something you'd have to be pretty careful about - making sure that it really is robust. Also, might it cause a problem for people who have an existing GeNN installation?

[mstimberg]

I agree that we should be careful about it. I think combining it with an exisiting GeNN installation should be fine, we already have a Brian2GeNN preference that can be used to specify the location of GeNN and which overwrites a GENN_PATH environment variable -- we'd use the same mechanism to take GeNN from some internal Brian2GeNN directory (possibly still allowing for an overwrite via a preference, but maybe not using GENN_PATH, or raising a warning if that one is also set).

[tnowotny]

I can see the appeal of a simple install. On the flip side, while future proofing against future changes in GeNN it would also exclude having the benefits from such changes. In the balance, I think, however, it's probably best to package it in because keeping everything compatible at all times would be tricky.
As for the compiled files: I think we are ok. The ones compiled in the GeNN directory are pretty much libgenn.a and libgenn_CPU_ONLY.a. Those can be pre-compiled. Then, generateALL and generateALL_CPU_ONLY need to be recompiled for each model but they are not put into the genn directory but the current directory of the model build, which is our GeNN_Workspace directory.
But I am pulling in @jamesturner246 to confirm?

[jamesturner246]

Yeah, that's right. I modified GeNN a little while ago to compile all the non-common user model and code generator stuff into the current directory. Like Thomas says, you just need to compile the common libgenn stuff and put it somewhere system-accessible, like /usr/local/lib64 or something - although it's currently just built in the GeNN directory.

[jamesturner246]

The aim was to put more of the code generation code inside this standalone library, so one didn't have to keep recompiling the code generation code with each project, but I ran into a few problems - with what I can't remember. Maybe I can have another crack at it one day.

[tnowotny]

Don't worry about that. Being practical, the current solution should work well with the packaging Marcel proposed. So no need to revisit this now.

[mstimberg]

So, I sneakily did a Brian2GeNN release, because you cannot really test the packaging/upload without doing a release... As you can see from the commit history, there were quite a few problems. However, it worked out in the end. we do now have a source code release on pypi (i.e., you can install with pip but then need a correctly configured installation of GeNN + GENN_PATH variable), and a conda package that ships its own version of GeNN (version 2.2.3) with pre-compiled libraries. Everything is done on the travis and appveyor build servers, i.e. there's no manual intervention necessary to do a release. With this package, anyone with an Anaconda install should be able to do a conda install -c brian-team brian2genn (with the current pre-releases, you also have to add -c brian-team/channel/dev) and they will get Brian2+Brian2GeNN+GeNN and all their dependencies. Users need to install CUDA themselves, though (there is actually a conda package for CUDA, but it only contains the runtime libraries, i.e. enough to run a compiled CUDA program but not the header files, etc. we need for compiling).

The only thing that did not quite work out: I did not manage to create the conda package with pre-compiled libraries for OS-X on travis. The reason is quite simple, for Windows and Linux I can download and install a minimal version of CUDA for the build process, but the minimal installation with the CUDA installer for OS-X still installs the full SDK with > 1GB -- this takes too long on the build server. So unfortunately we'll need someone with a Mac (ahem, @tnowotny maybe :) ) to manually build the conda packages for OS X. It shouldn't be very complicated: you need to have anaconda (or miniconda), and install the cond-build package (conda install conda-build). Then, running scripts/build_conda_packages.py from the brian2genn repository should take care of everything, and result in three .tar.bz2 files in the directory from which you started the script, one for Python 2.7, 3.5, and 3.6. You can in principle upload them yourself (since you are a member of brian-team), but the easiest is probably to just send them to me and I will upload them.

Could you maybe try (and have friends&family try) the conda packages and/or the pypi source package on your machine and see whether it works for you? To recap, to install from source (needs installed GeNN and GENN_PATH set):

pip install brian2genn

To install via conda (the .../dev part will no longer be necessary after the "proper" 1.0 release)

conda install -c brian-team -c brian-team/channel/dev brian2genn

If GeNN is installed with the package (i.e. if you use the conda install), then this version of GeNN will be used, otherwise you need to define GENN_PATH. I sometimes encountered problems when the installed GeNN version is used, but GENN_PATH is set at the same time. I fixed this in master, but the fix is not yet in the released version. So, if you test the conda installation, make sure to unset GENN_PATH variable before running anything.

Well, if all this works fine, I think we are finally ready to do an official 1.0 release 🎉 !

[mstimberg]

I fixed this in master, but the fix is not yet in the released version. So, if you test the conda installation, make sure to unset GENN_PATH variable before running anything.

FYI: This is no longer necessary, I did another release (1.0rc4) which includes the fix.

Oh, unrelated to the packaging (I think), but maybe interesting for @tnowotny , @jamesturner246 , @neworderofjamie & co.: it seems that Brian2GeNN does not work on Windows for the latest version of GeNN from the development branch due to linking issues. I did not look into this in detail, but I think it is rather a GeNN-internal issue. For error messages, see here for example: https://ci.appveyor.com/project/brianteam/brian2genn/build/1.0.156/job/scyjx6bblbqmaxty (note that this runs GeNN in CPU-only mode, as this is all that we can test on these servers).

[neworderofjamie]

Good spot - I was planning on bringing my Windows laptop in tomorrow for other reasons but I'll figure out what's going wrong! Do you know what version of Visual Studio the AppVeyor instances run?

[mstimberg]

Do you know what version of Visual Studio the AppVeyor instances run?

It's configurable but in our case we use the default image which comes with Visual Studio 2015.

[neworderofjamie]

If you could try re-running the tests that would be great! Thinking about it, I suspect it was something obvious

[mstimberg]

We have test runs in the queue, they will pick up the latest state of the development branch automatically. Results should be in in 30 minutes or so.

[tnowotny]

I tried building the conda packages on my mac. It fails with

Package: brian2genn-1.0rc4-py27_0
source tree in: /home/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497881603190/work
+ source /home/t/tn/tn41/anaconda2/bin/activate /home/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497881603190/_b_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placeho
++ pwd
+ GENN_PATH=/Volumes/LocalDataHD/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497881603190/work/genn
+ cd genn/lib
/home/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497881603190/work/conda_build.sh: line 5: cd: genn/lib: No such file or directory
Traceback (most recent call last):
  File "scripts/build_conda_packages.py", line 22, in <module>
    main_build()
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/cli/main_build.py", line 334, in main
    execute(sys.argv[1:])
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/cli/main_build.py", line 325, in execute
    noverify=args.no_verify)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/api.py", line 97, in build
    need_source_download=need_source_download, config=config)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/build.py", line 1518, in build_tree
    config=config)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/build.py", line 1143, in build
    utils.check_call_env(cmd, env=env, cwd=src_dir)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/utils.py", line 628, in check_call_env
    return _func_defaulting_env_to_os_environ(subprocess.check_call, *popenargs, **kwargs)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/utils.py", line 624, in _func_defaulting_env_to_os_environ
    return func(_args, **kwargs)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/subprocess.py", line 186, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/bin/bash', '-x', '-e', '/home/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497881603190/work/conda_build.sh']' returned non-zero exit status 1

I looked in to the genn folder and it is indeed empty. Did you install genn by hand into this folder up front? Is it expecting a standard genn install in there?

[tnowotny]

BTW: /home/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497881603190/work/genn also empty

[mstimberg]

I looked in to the genn folder and it is indeed empty. Did you install genn by hand into this folder up front? Is it expecting a standard genn install in there?

Ah sorry, my bad, I forgot about this. This is using fancy "git submodules" which allow you to have a reference to another git respository within a git repository (so we can always update the GeNN version). You'll have to run git submodule init and git submodule update to populate the GeNN directory.

[mstimberg]

Just for future reference: if you clone brian2genn from scratch, you can use --recursive to directly fill the genn directory.

[tnowotny]

hum ... getting compilation errors now that look like genn bugs:

      no member named 'max_digits10' in 'std::numeric_limits<double>'; did you
      mean 'digits10'?
        stream.precision(std::numeric_limits<double>::max_digits10);
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
                                                      digits10
/usr/include/c++/4.2.1/limits:1049:24: note: 'digits10' declared here
      static const int digits10 = __DBL_DIG__;
                       ^
/Volumes/LocalDataHD/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497882334764/work/genn/lib/src/stringUtils.cc:258:55: error: 
      no member named 'max_digits10' in 'std::numeric_limits<double>'; did you
      mean 'digits10'?
        stream.precision(std::numeric_limits<double>::max_digits10);
                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~
                                                      digits10
/usr/include/c++/4.2.1/limits:1049:24: note: 'digits10' declared here
      static const int digits10 = __DBL_DIG__;
                       ^

But also:

      use of undeclared identifier 'to_string'; did you mean 'toString'?
  ...== POISSONNEURON) substitute(wCode, "$(V_pre)", to_string(model.neuronPa...
                                                     ^~~~~~~~~
                                                     toString

which seems like a straightforward name mis-spelling ...?

[neworderofjamie]

Well our automated testing is testing that same code on your Mac so I don't think those are GeNN bugs per se. Perhaps some Clang compiler flags are being set wrong? Those look like they could be C++11 issues.

[tnowotny]

this is the GeNN 2.2.3 release I think ... was that tested on my Mac?

[tnowotny]

Command issued by make was
clang++ -std=c++11 -DNVCC=\""/usr/local/cuda/bin/nvcc"\" -MMD -MP -c -o /Volumes/LocalDataHD/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497882334764/work/genn/lib/obj/stringUtils.o /Volumes/LocalDataHD/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497882334764/work/genn/lib/src/stringUtils.cc -I"/Volumes/LocalDataHD/t/tn/tn41/anaconda2/conda-bld/brian2genn_1497882334764/work/genn/lib/include" -I"/usr/local/cuda/include"
which looks ok regarding flags ... or am I missing something?

[mstimberg]

I remember some problem like this, I think it might be mixing up gcc and clang. Could you check if it works if in the conda_recipe/meta.yaml file, you remove the two lines that say - gcc # [not win]?

[tnowotny]

hum ... doesn't seem to make a difference

[tnowotny]

But I agree with @neworderofjamie that it looks like issues with the C++11 standard ... even though -std=c++11 is given ...
Even more strange: If I try the same command line in the terminal interactively it succeeds to compile stringUtils.o
Any ideas?

[mstimberg]

hmm, let's narrow it down:
if, from the main brian2genn directory, you run:

bash conda_recipe/build.sh

does it work? This is the same what gets called during the package build process. If this works, then the build environment is to blame.

[tnowotny]

yes ... this works ...

[mstimberg]

Ok. I still have a hunch that the gcc line in meta.yaml is to blame -- you are sure that you removed both of them, right? Maybe the build environment has some cached results in it, could you increase the number in the build section to 1?

[tnowotny]

ok ... I think we have overcome this problem ... the next one is this:

Missing dependency brian2genn, but found recipe directory, so building brian2genn first
Traceback (most recent call last):
  File "scripts/build_conda_packages.py", line 22, in <module>
    main_build()
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/cli/main_build.py", line 334, in main
    execute(sys.argv[1:])
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/cli/main_build.py", line 325, in execute
    noverify=args.no_verify)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/api.py", line 97, in build
    need_source_download=need_source_download, config=config)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/build.py", line 1501, in build_tree
    config=config)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/render.py", line 145, in render_recipe
    m = MetaData(recipe_dir, config=config)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/metadata.py", line 422, in __init__
    self.meta_path = find_recipe(path)
  File "/home/t/tn/tn41/anaconda2/lib/python2.7/site-packages/conda_build/utils.py", line 726, in find_recipe
    raise IOError("No meta.yaml or conda.yaml files found in %s" % path)
IOError: No meta.yaml or conda.yaml files found in /Volumes/LocalDataHD/t/tn/tn41/localdisk_projects/develop/brian2genn/brian2genn

I don't understand too much of it but it seems it is looking for more recipe files meta.yaml or conda.yaml for brian2genn proper?

[mstimberg]

Hmm, not sure about this. It might be that the little Python script I wrote is not very robust with respect to paths... When we build packages, we run it from the main directory (i.e. with python scripts/build_conda_packages.py) -- did you do this as well?
But I've never seen that first line about the "Missing dependency", maybe that's the real problem? Could you maybe paste the full output somewhere?

[tnowotny]

There are some anomalities with my anaconda install
conda config --show
gives

add_anaconda_token: True
add_pip_as_python_dependency: True
allow_non_channel_urls: True
allow_softlinks: True
always_copy: False
always_softlink: False
always_yes: False
anaconda_upload: None
auto_update_conda: True
changeps1: True
channel_alias: https://conda.anaconda.org
channel_priority: True
channels:
  - defaults
client_ssl_cert: None
client_ssl_cert_key: None
clobber: False
create_default_packages: []
custom_channels:
  pkgs/r: https://repo.continuum.io/
  home/tn41/anaconda2/conda-bld: file:///
  pkgs/pro: https://repo.continuum.io/
  pkgs/free: https://repo.continuum.io/
custom_multichannels:
  local: ["file:///home/tn41/anaconda2/conda-bld"]
  defaults: ["https://repo.continuum.io/pkgs/free", "https://repo.continuum.io/pkgs/r", "https://repo.continuum.io/pkgs/pro"]
default_channels:
  - https://repo.continuum.io/pkgs/free
  - https://repo.continuum.io/pkgs/r
  - https://repo.continuum.io/pkgs/pro
disallow: []
envs_dirs:
  - /home/t/tn/tn41/anaconda2/envs
  - /home/t/tn/tn41/.conda/envs
force: False
json: False
local_repodata_ttl: 1
migrated_channel_aliases: []
offline: False
path_conflict: clobber
pinned_packages: []
pkgs_dirs:
  - /home/t/tn/tn41/anaconda2/pkgs
  - /home/t/tn/tn41/.conda/pkgs
proxy_servers: {}
quiet: False
remote_connect_timeout_secs: 9.15
remote_max_retries: 3
remote_read_timeout_secs: 60.0
rollback_enabled: True
shortcuts: True
show_channel_urls: None
ssl_verify: True
track_features: []
use_pip: True
verbosity: 0

where file:///home/tn41/anaconda2/conda-bld is nonsense ... it ought to be file:///home/t/tn/tn41/anaconda2/conda-bld
not sure this is relevant or how to fix it ... must be a bug in anaconda installer

[mstimberg]

I have no idea what is going on there... Maybe last try: update conda/conda-build with conda update conda conda-build, delete the build directory in your brian2genn folder, run conda build purge and then try python scripts/build_conda_packages.py again -- maybe this magically fixes stuff. Oh and your output also warns that you don't have CUDA_PATH set -- you'd normally need this to build the GeNN packages (it seems they are already built in your case, though).

Sorry for this annoying remote-debugging, if only Apple would allow me to have an OS-X virtual machine... 🙄

[tnowotny]

hi again ... I tried all that and also installed anaconda for python 3.6 (I had the 2.7 version before) but no change. I am worried that this nonsense might be causing the problem:

WARNING: The remote server could not find the noarch directory for the
requested channel with url: file:///t/tn/home/tn41/anaconda3/conda-bld

But I have no clue where this mangled channel url is coming from. Should have been

file:///home/t/tn/tn41/anaconda3/conda-bld

[mstimberg]

This indeed looks weird and I also have no idea where it could come from... I know all this is annoying, but maybe you could do a fresh anaconda/miniconda installation in parallel? If you manually change the PATH within your session to use that one instead of the old one, it would not affect your main installation. At least we'd be sure that your installation is to blame if it works with the new one...

[tnowotny]

can do ... in the meantime ... can you have a look whether the packages I made and sent you by email are any good? All I did was removing the test section from the recipe. That shouldn't affect the results I would have thought.

[tnowotny]

ok ... tried miniconda ... same problem with testing as before ... also the weird channel name.

[mstimberg]

can do ... in the meantime ... can you have a look whether the packages I made and sent you by email are any good? All I did was removing the test section from the recipe. That shouldn't affect the results I would have thought.

I did not receive any email with packages, I'm afraid... I'm not too surprised that it works if you remove the testing, it seems that on your system for some weird reason it does not find the package it just built during the testing phase, leading to all kind of error messages about missing files, etc. I'm happy to upload any packages you send me -- I cannot really test them, though, as you need a Mac for that.
But after I upload them, you could try to install them via anaconda as I described earlier. If that works, I guess all is good.

[mstimberg]

Oh, forgot about it: @neworderofjamie the tests on Windows against GeNN's development branch are now working fine, seems your commit was all that was needed.

[tnowotny]

I sent the email to Marcel Stimberg marcel.stimberg@inserm.fr
Is that the correct address?

[mstimberg]

Is that the correct address?

It is. Maybe it landed in INSERM's spam filter, I might get a notification about it later...

[tnowotny]

Oh boy ... I am not sure we should be that patient ... I have added and pushed the packages to the brian2genn repo
Feel free to remove them again at a future date ...

[mstimberg]

Thanks for the packages, I uploaded them to the anaconda server.
Could you try installing them (e.g. in your fresh miniconda environment) via:

conda install -c brian-team -c brian-team/channel/dev brian2genn

And then try running one of the example scripts with it? (Maybe put an import brian2genn; print(brian2genn.__file__) at the start to make sure it actually uses the freshly installed version).

[tnowotny]

Hum ... it almost works ... there is a problem with GENN_PATH. Presumably it should in my case point to $HOME/miniconda3/opt/genn
but the buildmodel.sh script complains it's not defined. How was this supposed to work generally? Who is setting that GENN_PATH appropriately?

[tnowotny]

PS: If I define the appropriate GeNN_PATH by hand, it is quashed somewhere in the brian2genn compile process.

[mstimberg]

If brian2genn comes with its own GeNN version, it should use it (you can add the line BrianLogger.log_level_debug() to your example script to get the debug output; it should say something like "Using GeNN path from installation: ...") and ignore the GENN_PATH variable (actually it will even unset it).

The GENN_PATH variable is directly defined within the brian2genn compile process and it is passed as a command line argument to the make files. I just realized that we don't pass it to genn-buildmodel.sh, though -- it works fine without on Linux because it autodetects it, but apparently this does not work on OS-X? Let me correct this.

[tnowotny]

Yes ... this seems to be the case. With the debug on I get

DEBUG      Using GeNN path from installation: "/home/t/tn/tn41/miniconda3/opt/genn" [brian2.devices.genn]
genn-buildmodel.sh:45: error 1: GENN_PATH is not defined

So it is planning to use the right genn install but somehow it doesn't get passed into the genn-buildmodel.sh script
I had a look at the buildmodel.sh script and it explicitly only attempts auto-detection of GENN_PATH in Linux.

[tnowotny]

for all it's worth I have implemented GENN_PATH auto-detection for Mac in the genn-buildmodel.sh script in our GeNN development branch ... but maybe too late to add it to GeNN 2.2.3

[mstimberg]

I fixed the GENN_PATH issue (so it should not need the autodetection on OS X for now) and a bunch of stuff related to the build process to make it more robust (I had some issues building it on my Windows VM as well). Maybe I fixed the OS X build issues as a side effect?
Could you update to latest master and run

python scripts/build_conda_packages.py

again? If it still fails during the testing phase, you can now do:

python scripts/build_conda_packages.py --no-test

instead of editing the meta.yaml file. If that works, please send me the file so I can upload them to the server and we can do another test of the packages.

[tnowotny]

I compiled the packages and tried to send to the google address. But it is returning the email because the "attachments pose a potential threat". I will send you a link instead.

[mstimberg]

I uploaded the packages again, could you re-try installing and using them?

[tnowotny]

It seems to work now! I have run the CUBA.py example. The only error I get is

[...]
executing genn binary on GPU ...
mkdir: test_output: File exists
# DT 0.000100 
# totalTime 1.000000 
# We are running with fixed time step 0.000100 
0.9999 done ...
everything finished.
ERROR      Brian 2 encountered an unexpected error. If you think this is bug in Brian 2, please report this issue either to the mailing list at <http://groups.google.com/group/brian-development/>, or to the issue tracker at <https://github.com/brian-team/brian2/issues>. Please include this file with debug information in your report: /var/folders/kz/40f73dyn64sglrctb07g8mqh0004z3/T/brian_debug_6vc8u5yq.log  Additionally, you can also include a copy of the script that was run, available at: /var/folders/kz/40f73dyn64sglrctb07g8mqh0004z3/T/brian_script_irnsc7y4.py You can also include a copy of the redirected std stream outputs, available at /var/folders/kz/40f73dyn64sglrctb07g8mqh0004z3/T/brian_stdout_49a7sr9f.log and /var/folders/kz/40f73dyn64sglrctb07g8mqh0004z3/T/brian_stderr_qs0v1m1v.log Thanks! [brian2]
Traceback (most recent call last):
  File "CUBA.py", line 52, in <module>
    plot(s_mon.t/ms, s_mon.i, ',k')
NameError: name 'plot' is not defined

I suspect this must be unrelated? The brian2genn stuff has most certainly finished at that point ...

[mstimberg]

Hey, great! I think you simply get the error because you are running it in an environment without matplotlib (it's an optional dependency for Brian, all we do is to import it into our namespace...).

[tnowotny]

I suppose we need not worry about that too much? Or do you think naive users would run into the same problem if downloading brian2genn was their very first exposure to brian 2?

[mstimberg]

I think it is fine, we should maybe document it a bit more (we do mention it in the Brian docs but not in the Brian2GeNN docs). I'll add a note in the docs, and, well I think then we are ready to do a proper 1.0 release, no? @thesamovar Could you maybe also have a go at trying to install it under Windows?
Oh, something I forgot to mention: there's now an easy way to do a very simple test:

>>> import brian2genn
>>> brian2genn.example_run()

We do this during the package build process as well (but with example_run(use_GPU=False) because we cannot be sure that CUDA is available).

[tnowotny]

Yes, I think we should be ready. Exciting. We can then think about publication again. I think @thesamovar had a point that a classical paper still carries some weight. The new thing in it would have to be comparative benchmarking (aside just describing what it is all about and how it roughly works).

[mstimberg]

I'm resurrecting this old thread, because I was looking into releasing brian2genn 1.2 (following GeNN's 3.2 release). As a reminder, we currently ship conda packages in our brian-team channel that come with pre-compiled libraries from GeNN, i.e. a user installing these packages will everything necessary from GeNN "for free".

This is kind of cool, but it comes with a few inconveniences. The first is that the packaging process is only half-automated (e.g. OS X packages have to be built by someone) and we cannot automate it further by putting things on conda-forge, since we need the CUDA compiler. The second inconvenience is that these packages simply do not always work due to incompatibilities between compilers/libraries etc., see e.g. #59.

I think all this is probably fixable, but I wonder whether it is really worth it for saving users one download + the setting of an environment variable... What do you think? If we remove this, users would have to install GeNN as detailed in the GeNN installation instructions (including setting GENN_PATH and CUDA_PATH) and then do a pip install brian2genn – still reasonably simple, I'd say.

[tnowotny]

To be honest, I think it is probably more future proof and less support-request heavy if we require users to install their own GeNN?

[mstimberg]

@tnowotny I think I agree... I'll open a PR that makes the change (basically: deletes a lot of stuff).