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.
Added a cut-down (3’s and 7’s) version of MNIST to /data. It’s 3MB, which is a bit big for something to put in the repo, but it allows us to have a single dataset for all our vision tutorials and notebooks. It contains a CSV and also keras-style folders.
1 Like
docs.fast.ai now has a sidebar with all links in place. (Not all the notebooks it links to are written yet.)
If you want to change the sidebar, use
docs_src/tools/make_sidebar.ipynb.
My vision.transform.ipynb weights 8.5MB :-/ … too many kittens?
More seriously, vision.transform.ipynb and vision.ipyng are more or less done. Will use the MNIST data to show examples of the data function at the end.
Initial packages are out in hidden channels:
conda
You can now experiment with fastai-1.0.0b conda package:
conda install -c pytorch -c fastai -c fastai/label/test fastai
Note that it’s invisible to normal users who may run:
conda install -c pytorch -c fastai fastai
They will still get the old fastai-0.7.
pip
And the test package on test.pypi.org is:
pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple/ fastai
Let me know if you encounter any problems with either of the two packages. In particular on windows. I am mainly concerned about dependencies. So if you get a chance please test.
1 Like
Quickly tried this and got:
PackagesNotFoundError: The following packages are not available from current channels:
- fastai
- dataclasses
- fastai
- fastprogress
- fastai
- fire
- fastai
- torchvision[version='>=0.2.1']
As you know, I’m on Windows