give newly created repositories non-default identifier about datalad HOT 6 CLOSED

It sounds like this is obsolete now. @yarikoptic please confirm and close if true.

from datalad.

I think it still remains...

In [1]: from datalad.support.annexrepo import AnnexRepo

In [2]: AnnexRepo('/tmp/123123', create=True)
Out[2]: <AnnexRepo path=/tmp/123123 (<class 'datalad.support.annexrepo.AnnexRepo'>)>

In [3]: 
[1]  + 12283 suspended  ipython
2 13310 ->148 [1].....................................:Tue 22 Mar 2016 01:36:12 PM CET:.
hopa:~datalad/datalad
$> cd /tmp/123123
W: git-annex repositories not (yet) supported in the prompt
2 13311 [1].....................................:Tue 22 Mar 2016 01:36:15 PM CET:.
hopa:/tmp/123123
$> git annex info
repository mode: indirect
trusted repositories: 0
semitrusted repositories: 3
    00000000-0000-0000-0000-000000000001 -- web
    00000000-0000-0000-0000-000000000002 -- bittorrent
    5d2773e2-6ebb-4c99-9ba4-77d320ec0667 -- yoh@hopa:/tmp/123123 [here]
...

but the point either we should come up with anything better or just leave it alone...

from datalad.

@yarikoptic Ah I misinterpreted the scope of "identifier". Indeed an open question.

from datalad.

I guess, the only thing obvious would be to use the "name" of a dataset,
using the full submodule name from toplevel (or just basename('.') if there
is no upper level. For example "openfmri/ds0001". But I'm not sure, whether
this is a good idea. If you have multiple installtions, it's still not an
"identifier". But this is true for anything we could possibly come up with,
as long as there is no central registry or sth. like this. So, the path at
least is not ambigous.

2016-03-22 13:40 GMT+01:00 Michael Hanke [email protected]:

@yarikoptic https://github.com/yarikoptic Ah I misinterpreted the scope
of "identifier". Indeed an open question.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#27 (comment)

from datalad.

well -- to some degree original/default descriptions are the best since they uniquely identify any given clone / remote where annexed content resides. But I don't think we should expose indeed internal paths which might change or pretty much might be "irrelevant" while sharing those datasets publicly. E.g. in Michael's I see a wide range of representative examples:

$> git annex info   
repository mode: indirect
trusted repositories: 0
semitrusted repositories: 8
    00000000-0000-0000-0000-000000000001 -- web
    00000000-0000-0000-0000-000000000002 -- bittorrent
    597f3147-141e-4c00-92db-5575aa69498e -- original source repository
    664fbb24-ba44-44e4-95ec-e455333e987f -- mih@medusa:/home/data/psyinf/forrest_gump/incoming
    731b805f-054e-485f-b3fc-79b460aa2482 -- Data graveyard
    cb9b9552-c3d8-4aaf-84ed-532381978235 -- yoh@hopa:~/proj/datalad/providers/forrest_gump [here]
    dd3d4b44-44f2-40d6-9d9e-30fd3ded5c26 -- original public releases (http://studyforrest.org) [origin]
    f15331bb-20fd-4d40-93d0-6b8445f89d2c -- mih@meiner:~/forrest/anondata

some are the "private" clones with default user@host:path, where some were provided manually. I like "original public releases (URL)" since it identifies where is that and provides some reference url. I don't like "Data graveyard" since it provides no contact reference. So may be we should adhere to smth like below given that this dataset's name was studyforrest/phase1

• datalad.org:studyforrest/phase1 (crawler)
• datalad.org:studyforrest/phase1 (public)
• datalad.org:studyforrest/phase1 (graveyard)
• ... with default paths from annex ...

?

from datalad.

This is so old that is was re-envisioned: #701 Moreover #682 provides get_dataset_identifier() in the metadata context.

from datalad.