There might be some valid points there, but some of the comments in that thread seem a bit too harsh. There are 341 topics with the word fastai on the Kaggle forums, which means people are successfully applying the library to competitions.
This may be true, but I have seen in other discussions negative comments regarding fastai. Most notably, I have seen some discussions in the kagglenoobs.slack.com general slack channel (which I unfortunately cannot link over here). But there is definitely some hesitancy to move to fastai or start learning fastai, some of which is due to the reasons I laid above. I wanted to mention this as these are definitely things to keep in mind during the development of fastai v2.
There are so many decisions that go into creating a library. Flexibility is important and I think v2 will probably be the most flexible incarnation of fastai yet. Software that is opinionated will always have critics. If fastai was backwards compatible, at least to me, it would lose a lot of appeal.
It would probably be very good to focus on understanding how v2 is constructed, at least that is my plan. I feel that if one approaches v2 with an open mind they will have a hell of a ride that they otherwise would miss.
15 Likes
I understand there are some decisions that need to be made that many may not be happy about but are worth it. I am simply trying to inform what the community thinks of fastai and why they haven’t adopted fastai and how we might be able to solve these issues. In terms of backwards compatibility, I think you can see why this is a hassle for many people. It’s also a hassle for me, but I think the benefits outweigh the disadvantages when it comes to relearning the library.
In terms of the other issues, I am not sure whether there are any software development decisions that can be made to solve these issues, but I think better documentation is the solution to that.
Software will always have critics but I think it is also important to take into consideration these criticisms to improve the software.
1 Like
I fully appreciate you have good intentions 
This is something we can all help with
4 Likes
Yes! I am currently working on two Kaggle competitions, but afterwards, I would love to help with documentation, especially after learning that it is one of the reasons some people are hesitant to adopt the library.
6 Likes
I’d like to be a part of this as well, as I am comfortable enough with the interior of the library to help in a few ways. Perhaps once you are done with those competitions, we can iron out a “to-do” list of sorts of what still needs to be documented and what people would like documented?
3 Likes
I would be interested in doing this. One competition finishes next week, and the other one finishes finishes in 3 weeks. Afterwards, we can discuss what needs to be documented. I am not sure whether we should start with fastai v1 or fastai v2. Maybe we can start with fastai v1 and hopefully a lot of that material can still be used for fastai v2.
1 Like
I believe a lot of it can be. If not tweaked ever so slightly. Once v2 is moreorless out I plan on using it in my meetups to teach, and I’ll have to get very familiar with the API fast, hence the offer.
Ok sounds good.
I think the plan (for me at least) would be to go through the codebase and write a to-do list on what I think needs to be documented in about 3 weeks. I will focus on things that I think will be pretty similar between the two libraries. I will post a topic over here, and we can discuss it further.
I think v2 will fix these issues. We’re certainly trying! There will always be room for more tutorials and docs, and contributions are most welcome.
We’re also writing an O’Reilly book about v2.
24 Likes
Wow! That’s amazing! I would be excited to buy it! And it will definitely lead to more people adopting fastai!
4 Likes
BTW one thing I’d like to do once v2 is out is to create a kaggle kernel starter kit for every new competition that comes out - both to show nice role models of how to do various things in fastai, and also to ensure that everything really is easy to do and understand.
21 Likes
I just started looking at notebook 01. I see the insist on documentation already. Like having test cases for documentation of all methods, this ensures that documentation is already available. Is there any place where we can see the documentation of complete classes. Sorry, for my ignorance, I just started looking into the code yesterday.
Every class is documented immediately after it’s defined. Run build_docs.py to generate a jekyll website in the docs subdirectory, which is in the same format as the v1 docs.
3 Likes
My desire for the library is to make the code more readable. Specifically don’t make the code as few lines as possible.
My opinion is the v1 codebase was very difficult to read.
Please take a look at the Django codebase as a great example.
I tried to run build_docs.py but could not proceed as it threw up an error saying there is module called fastai. There is a line in the code that says “from fastai.script import *”. Do we need to import fastai for running this?
Do you mind if I remove the line torch.cuda.set_device(int(os.environ.get('DEFAULT_GPU') or 0)) that appears on top of some of the notebooks (13 atm). It’s only useful for minority of the users and there is already CUDA_VISIBLE_DEVICES variable you can use to mask and reorder your devices without code changes. For the rest of us it’s extra clutter and a source of errors where no cuda is available.
Alternatively wrap it in something like if torch.cuda.is_available():
I can do that - it’s meant to only be in one place now (01_core). I can wrap it there so it works on non-GPU machines.
OK done now.