distributing ebuild via .gentoo directory

We talked about how it might make sense to distribute an ebuild instead of a deps list, this would:

ease transitioning the package from a top-level unintegrated graph node to a fully integrated node in the software dependency environment.
allow us better control over the tests (tests could be expressed in a testing-platform-independent eclass-aided fashion, rather than having to write a new file for whatever CI provider one is using)
be overall more sustainable for maintainers and accessible for new user. We would reduce the number of new/uncommon ways in which we handle dependency management.

This ofc leads to the issue which we stumbled upon yesterday, namely that emerging by path is difficult. The ebuild command apparently does no dependency resolution, whereas emerge does this:

*** emerging by path is broken and may not always work!!!

These are the packages that would be merged, in order:

Calculating dependencies - * Manifest not found for '/home/hioanas/src/SAMRI/.gentoo/sci-biology/samri/samri-9999.ebuild'

*** You are emerging a masked package. It is MUCH better to use
*** /etc/portage/package.* to accomplish this. See portage(5) man
*** page for details.
>>> Waiting 10 seconds before starting...
>>> (Control-C to abort)...
Continuing... in: 10 9 8 7 6 5 4 3 2 1
... done!
Traceback (most recent call last):
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/depgraph.py", line 6846, in _pkg
    metadata = zip(db_keys, db.aux_get(cpv, db_keys, myrepo=myrepo))
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/portage/dbapi/porttree.py", line 620, in aux_get
    raise PortageKeyError(mycpv)
portage.exception.PortageKeyError: 'sci-biology/samri-9999'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/hioanas/gentoo/usr/lib/python-exec/python3.4/emerge", line 50, in <module>
    retval = emerge_main()
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/main.py", line 1250, in emerge_main
    return run_action(emerge_config)
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/actions.py", line 3297, in run_action
    retval = action_build(emerge_config, spinner=spinner)
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/actions.py", line 339, in action_build
    settings, trees, myopts, myparams, myaction, myfiles, spinner)
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/depgraph.py", line 9601, in backtrack_depgraph
    myaction, myfiles, spinner)
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/depgraph.py", line 9638, in _backtrack_depgraph
    success, favorites = mydepgraph.select_files(myfiles)
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/depgraph.py", line 3813, in select_files
    return self._select_files(args)
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/depgraph.py", line 3915, in _select_files
    os.path.dirname(os.path.dirname(os.path.dirname(ebuild_path)))))
  File "/home/hioanas/gentoo/usr/lib64/python3.4/site-packages/_emerge/depgraph.py", line 6848, in _pkg
    raise portage.exception.PackageNotFound(cpv)
portage.exception.PackageNotFound: sci-biology/samri-9999

Ok, so distributing an ebuild really requires us to set up an overlay. Unless there's an (easy) way to mainline an update which lets portage use "anonymous" overlays or improve support for emerging from path, we would have to deal with this. The extra files required are few (~3), the only real problem is decreasing transparency for people who are unfamiliar with what an overlay is.

One issue which may be solved by the developer explicitly or by our system implicitly is the manifest generation:

!!! Repository 'samri_gentoo' is missing masters attribute in '/home/hioanas/src/SAMRI/.gentoo/metadata/layout.conf'
!!! Set 'masters = gentoo' in this file for future compatibility

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N    *] sci-biology/afni-9999::neurogentoo  0 KiB
[ebuild  N    *] sci-biology/samri-9999::samri_gentoo  PYTHON_TARGETS="python2_7 python3_4 -python3_5" 0 KiB

Total: 2 packages (2 new), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
!!! A file is not listed in the Manifest: '/home/hioanas/src/SAMRI/.gentoo/sci-biology/samri/samri-9999.ebuild'

Implicit:

Pros:
- Easier, less overhead for developers
- One less "meaningless" file to track
Cons:
- More work/overhead for our system
- Doesn't give control for when to build a new testing environment directly to the developer (this could also be a pro, tho).

IBT-FMI / NeuroGentooProject

distributing ebuild via .gentoo directory #2