Yay it looks like this doc template may just work nicely! I just manually popped in one page for testing, and it’s looking pretty good without even customizing anything much at all:
5 Likes
Hmm, are you able to run dev_nb/002_images.ipynb?
I have to change the first cell to even find gen_doc:
- import sys
- sys.path.append('../docs')
to:
+ import pathlib, sys
+ path = str((pathlib.Path(".")/".."/"fastai").resolve())
+ if path not in sys.path: sys.path.insert(0, path)
there are no python libs under fastai_v1/docs, not sure how it worked…
and then once the path has been fixed it fails internally:
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
<ipython-input-2-2e0a20ad4bf5> in <module>()
7 if path not in sys.path: sys.path.insert(0, str(path))
8 sys.path
----> 9 from gen_doc.nbdoc import show_doc as sd
/mnt/disc1/fast.ai-1/br/fastai/master/fastai/gen_doc/nbdoc.py in <module>()
3 from typing import Dict, Any, AnyStr, List, Sequence, TypeVar, Tuple, Optional, Union
4 from .docstrings import *
----> 5 from .core import *
6
7 __all__ = ['get_class_toc', 'get_fn_link', 'get_module_toc', 'show_doc', 'show_doc_from_name',
/mnt/disc1/fast.ai-1/br/fastai/master/fastai/gen_doc/core.py in <module>()
----> 1 from ..core import *
2 import re
3
4 def strip_fastai(s): return re.sub(r'^fastai\.', '', s)
5
ValueError: attempted relative import beyond top-level packageMade some little moves in this commit
- It made more sense to have DatasetBase and LabelDataset in data
- I renamed all the data_from_* function to something more consistent like {type}_data_from_* so for instance image_data_from_folder, text_data_from_tokens or tabular_data_from_df.
- Then I changed all the references to those functions in the example notebooks.
Fixed now.
1 Like
Hmm, are you able to run
dev_nb/002_images.ipynb
Fixed now.
ModuleNotFoundError: No module named 'fastai'
Are notebooks now supposed to rely on a pre-installed fastai as being discussed in the other thread?
Otherwise the following would remove such requirement:
import pathlib, sys
path = str((pathlib.Path(".")/"..").resolve())
if path not in sys.path: sys.path.insert(0, path)Yes you need to follow the directions in the other thread.
ln -s ../fastai . did the trick 
Is there a special reason why in v1 we switched from:
%reload_ext autoreload
to:
%load_ext autoreload
?
Currently v1 nbs get:
The autoreload extension is already loaded. To reload it, use:
%reload_ext autoreload
when re-running the cells.
No I didn’t notice I’d done that! reload does seem better. Feel free to change it! 
Done. Thank you.
FYI, I started working on packaging and created ‘package’ branch for it. It will be a slow start as I’m following a tutorial, but hopefully it’ll go faster once I figure it out. And Jeremy already created setup.py so it’s a good start.
And we need to finalize the renaming anyway before we can upload anything to pypi and friends.
Perhaps it’s time to introduce fastai.__version__?
where should we have the source for this? in the code, or the build configuration?
Here is how pytorch does it: torch/__init__.py contains:
from .version import __version__
and version.py is autogenerated by setup.py, and the version number is hardcoded in this same file:
version = '1.0.0a0'
class create_version_file(PytorchCommand):
def run(self):
global version, cwd
print('-- Building version ' + version)
version_path = os.path.join(cwd, 'torch', 'version.py')
with open(version_path, 'w') as f:
f.write("__version__ = '{}'\n".format(version))
so their source is setup.py.
Should I copy this same setup?
Except it’ll make it impossible to using fastai w/o building/installing it first, as version.py won’t exist otherwise and import fastai will fail. Of course version.py can also be committed and simply updated during build, as long as we remember to never modify it by hand and change setup.py instead.
Jeremy, I remember you were also talking about deriving the version number from the git tag? or did you mean it the other way around - git tag based on setup.py hardcoded version number?
I think yes, because we could still commit version.py to git, right?
I suspect that way around might be easier, but I can’t say I’ve thought it through carefully, so happy to accept whatever you think is likely to be most convenient.
pytorch doesn’t, but we can.
So I will go ahead and add the build code to create it, OK? This is all part of the packaging.
git tag based on setup.py hardcoded version number
I suspect that way around might be easier, but I can’t say I’ve thought it through carefully, so happy to accept whatever you think is likely to be most convenient.
At the moment I think that setup.py should be the center of it all, but of course we can change it later if we find out a better way.
1 Like
The start of the docs site is now online. Almost nothing in it yet though.
5 Likes
Hi guys, did you read my reply? I cannot seem to find what I posted yesterday.
Please note: fast_progress has been renamed fastprogress because the _ was making conda break.
This looks pretty good! Might be a repeat question, plan is that all documentation related files live in the /doc folder? The function annotations in fastai_v1 make the code quite readable, was curious if these could be ‘reused’ for documentation also.
Yes. They’re auto-generated from docs_src/. And the function annotations will appear in the docs automatically. (Some details of that still being finalized thanks to @ashaw ).
1 Like
Sorry Jan now isn’t a great time to be jumping in - our release is on Tuesday. I deleted your post because it covered stuff that’s been discussed many times before and we don’t have time to cover it again right now. Sorry I should have said that at the time instead of deleting it.