Developer chat


(Jeremy Howard) #41

Yes you need to follow the directions in the other thread.


(Stas Bekman) #42

ln -s ../fastai . did the trick :wink:


(Stas Bekman) #43

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.


(Jeremy Howard) #44

No I didn’t notice I’d done that! reload does seem better. Feel free to change it! :slight_smile:


(Stas Bekman) #45

Done. Thank you.


(Stas Bekman) #46

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.


(Stas Bekman) #47

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?


(Jeremy Howard) #48

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.


(Stas Bekman) #49

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.


(Jeremy Howard) #51

The start of the docs site is now online. Almost nothing in it yet though.

http://docs.fast.ai/


(Jan Gazda) #52

Hi guys, did you read my reply? I cannot seem to find what I posted yesterday.


#53

Please note: fast_progress has been renamed fastprogress because the _ was making conda break.


(Nikhil B ) #54

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.


(Jeremy Howard) #55

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 ).


(Jeremy Howard) #56

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.


(Jeremy Howard) #57

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.


(Jeremy Howard) #58

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.


#59

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.


(Stas Bekman) #60

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.


#61

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