Git Product home page Git Product logo

jupyter-fs's Introduction

jupyter-fs

build status pypi package npm package

A plugin for JupyterLab that lets you set up and use as many filebrowsers as you like, connected to whatever local and/or remote filesystem-like resources you want.

The backend is built on top of PyFilesystem, while the frontend is built on top of JupyterLab Filetree.

Install

pip install jupyter-fs

Configure

Add the following to your jupyter_server_config.json:

{
  "ServerApp": {
    "contents_manager_class": "jupyterfs.metamanager.MetaManager",
    "jpserver_extensions": {
      "jupyterfs.extension": true
    }
  }
}

Simple use (no auth/credentials)

Add specifications for additional contents managers in your user settings (in the Settings menu under Advanced Settings Editor -> jupyter-fs). Here's an example config that sets up several new filebrowsers side-by-side:

{
  "resources": [
    {
      "name": "root at test dir",
      "url": "osfs:///Users/foo/test"
    },
    {
      "name": "s3 test bucket",
      "url": "s3://test"
    },
    {
      "name": "s3 test key",
      "url": "s3://test-2/prefix/",
      "defaultWritable": false
    },
    {
      "name": "samba guest share",
      "url": "smb://[email protected]/test?name-port=3669"
    }
  ]
}

You should see your new filebrowsers pop up in the left-hand sidebar instantly when you save your settings:

Use with auth/credentials

Any stretch of a "url" that is enclosed in double-brackets {{VAR}} will be treated as a template, and will be handled by jupyter-fs's auth system. For example, you can pass a username/password to the "samba guest share" resource in the Simple use example above by modifying its "url" like so:

{
  "resources": [
    ...

    {
      "name": "samba share",
      "url": "smb://{{user}}:{{passwd}}@127.0.0.1/test?name-port=3669"
    }
  ]
}

When you save the above "resouces" config, a dialog box will pop asking for the username and passwd values:

Once you enter those values and hit ok, the new filebrowsers will then immediately appear in the sidebar:

The auth dialog will only appear when needed

The jupyter-fs auth dialog will only appear when:

  • JupyterLab first loads, if any fs resources reqiure auth
  • a new fs resouce is added that requires auth, or its "url" field is modified

Supported filesystems

The type of resource each filebrowser will point to is determined by the protocol at the start of its url:

  • osfs: os filesystem. The will open a new view of your local filesystem, with the specified root
  • s3: opens a filesystem pointing to an Amazon S3 bucket
  • smb: opens a filesystem pointing to a Samba share

jupyter-fs can open a filebrowser pointing to any of the diverse resources supported by PyFilesystem. Currently, we test only test the S3 and smb/samba backends as part of our CI, so your milleage may vary with the other PyFilesystem backends.

The filesystem url

The "url" field jupyter-fs config is based on the PyFilesystem opener url standard. For more info on how to write these urls, see the documentation of the relevant PyFilesystem plugin:

Server-side settings

If you prefer to set up your filesystem resources in the server-side config, you can do so. For example, you can set up a local filesystem by adding the following to your jupyter_server_config.py file:

c.JupyterFs.resources = [
    {
        "name": "local_test",
        "url": "osfs:///Users/foo/test"
    },
]

ALternatively, you can add resource specifications alongside the basic jupyter-fs config in your jupyter_server_config.json file:

{
  "ServerApp": {
    "contents_manager_class": "jupyterfs.metamanager.MetaManager",
    "jpserver_extensions": {
      "jupyterfs.extension": true
    }
  },
  "JupyterFs": {
    "resources": [
      {
        "name": "local_test",
        "url": "osfs:///Users/foo/test"
      }
    ]
  }
}

Any filesystem resources specified in any server-side config file will be merged with the resources given in a user's settings.

Development

See CONTRIBUTING.md for guidelines.

License

This software is licensed under the Apache 2.0 license. See the LICENSE and AUTHORS files for details.

jupyter-fs's People

Contributors

ceball avatar davemalvin avatar dependabot[bot] avatar jacob-frazer avatar jpmckmb avatar logan-hcg avatar mahendrapaipuri avatar manthankeim avatar paulkgrimes avatar reoono avatar telamonian avatar timkpaine avatar vidartf avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jupyter-fs's Issues

Immediate UI Needs

Let's use this as a spot to dump UI needs, questions to ask, user stories, and discussions.

Setup via jupyter_notebook_config.py not respected (Server-Side Settings)

Hello all, I've read through the readme, and am trying to figure out if what I am doing is wrong, and this is expected, or if I should be able to achieve this (which for me, all setup occurs in jupyter_notebook_config.py, I do this so I can automate this install for folks).

Essentially,

I inferred from the Readme (Note: If this is accurate, we should make this explicit under Server-Side Settings) that I can put this in the jupyter_notebook_config.py to set the contents_manager_class and enabled the plugin.

c.NotebookApp.contents_manager_class = "jupyterfs.metamanager.MetaManager"
c.NotebookApp.nbserver_extensions = {"jupyterfs.extension": True}

Then, per the Server-Side Settings (This part IS explicit) I added a couple of locations for testing:

c.Jupyterfs.resources = [
    {
        "name": "mytest1",
        "url": "osfs:///Users/iamgroot/Notebooks"
    },
    {
        "name": "mytest2",
        "url": "osfs:///Users/iamgroot"
    },
]

When I restart my notebook server this does NOT work.

Nothing new appears.
However, when I open the Advanced Settings Editor, go to jupyter-fs and add:

{
	"resources": [
    {
        "name": "mytest1",
        "url": "osfs:///Users/iamgroot/Notebooks"
    },
    {
        "name": "mytest2",
        "url": "osfs:///Users/iamgroot"
    }
    ]
}

Then I get two new items with the proper root as expected.

Note, when I do this, I don't change the jupyter_notebook_config.py so all the other information is there

I am using Anaconda, I am not sure if that could affect things.

Essentially, I would like to be able to do ALL the setup in the jupyter_notebook_config.py without having to touch any of the json files/UI settings. This allows me to automate a setup for my users.

Any thoughts would be appreciated.

jlab3 upgrade/release planning

here's my plan for the jlab3 upgrade and surrounding releases. Feedback is welcome:

  • revert #85, split out autoformat tweaks and jlab3 upgrade code from the #85 changeset into two separate PRs
  • decide on "final" autoformat rules for this repo, merge in autoformat tweaks
  • do a final jlab 2.x compatible release of jupyter-fs, tag as either v0.1.0 or v0.2.0
  • merge in jlab3 updgrade code
  • do first jlab 3.x compatible release

Turn appveyor on for this repo

Our windows ci uses appveyor. appveyor is turned on for my fork at telamonian/jupyter-fs, so I can get the windows ci results for my own pull requests. However, it's output is not displayed alongside our other ci tests, and if anyone other than me submits a PR they probably won't run the windows ci at all.

We should fix this

Clean up old comments

On pull requests that are in active development, jupyter-fs comments can become redundant. and making reading and contributing to other discussions on the same PR difficult. It would be great if jupyter-fs had a command that cleans up its old comments.

Ideally, something like jupyter-fs prune to manually invoke it. This invocation might delete all but the last comment; something like jupyter-fs prune --last 4 might delete the last four comments,

Design Update

tl;dr: These aren't the final designs, they're just some things we tried along the way. We're doing more testing and iterating before we arrive at a final design.


We’ve been continuing our research on file system design, and while we don’t have a final design ready to share, we have arrived at a direction to take with the design. More to come on that.
For now, in the interest of openness, we’d like to share some of our progress, and document some of the steps we’ve taken along the way.
There is, of course, our previous research that we’ve shared. We also shared some of our early wireframes, as we were just beginning to put pen to paper. Since then, we’ve had the opportunity to work more with the Jovyan community, and learned a lot about the specifics of how Jupyter users expect a file system to work, and what they need from their file browser going forward.
Using the data we had gathered from our interviews and heuristic evaluation, we started down two different design tracks, allowing ourselves to explore these alternatives so we wouldn’t get ourselves stuck in a rut, fixated on a single concept early on.

Concept 1: "Mac Finder Lite"

The first of these, "Mac Finder Lite," as we called it, would move the file browser from the left-hand sidebar into the main work area. This concept tested well with users who are newer to Jupyter Lab. However, it requires a big mental model shift for the more experienced users — and also represents a significant amount of development effort. Here’s some of those wireframes:
01
02
03
04
05
06
07

Concept 2: "Launcher Add-On"

The second, "Launcher Add-On," would keep the file browser in the sidebar, but offer the ability to open multiple browsers at once. This concept was much more popular with the more experienced users of Jupyter Lab, and is a better fit for the existing mental model, while still gaining some of the more powerful features many users requested in interviews. Take a look:
11
12
13
14

Moving Forward

Having done our exploratory designs, we’re looking forward to the direction to take with the final design. "Launcher Add-On" is a better fit for Jupyter Lab, and will be the primary focus of our future designs; however, we did learn some valuable things from "Mac Finder Lite," and will be offering those findings as recommended next-steps to the Jupyter team.
As we move forward, we’re redoubling our focus on two key problems, which we heard from every Jupyter user that we talked with: finding the right files, and organizing them once you’ve found them. These aren’t the only problems we want to address, but they’re the two universal problems, and so they’re our primary focus.
We’re going to develop a consolidated design and take it through a few rounds of user testing. As of this writing, we’ve got a few sketches, which we’ll be developing into wireframes, and we’ll share those wireframes when appropriate. (We’d share some sketches, but speaking for myself, my handwriting is so atrocious that they’re not worth the effort to scan and upload.)
Thank you for reading, and we hope that this update gives you a good view into our design process. We do, of course, welcome feedback on these design artifacts, but keep in mind that these are not the final design. Don’t get too attached, and feel free to point out any issues - we’d hate to bring something forward because we didn’t realize there was an issue.
Thanks,
The UCI team: @jabumeri, @JDLEarley, @emilythefan, @Nastraughn, and myself

JupyterLab FS Competitive Analysis

Hello from the UC Irvine team! We’ve been doing a lot of research on file systems, and have put together a competitive analysis, looking at other file browsing/management UIs to see what the best practices are, and what cool/useful ideas we should steal borrow.

At the moment, I’m linking to the document as stored in my personal .github.io repo; we’re hoping @tgeorgeux can get us a better permanent place to store these, to clarify that they belong to the Jupyter community. Once that happens, I’ll come back and link to the new location.

We also did a heuristic evaluation of the current file manager in JupyterLab, which we’ve posted as jupyter/design#63, if you’re interested.

Thanks,

The UCI team: @jabumeri, @JDLEarley, @emilythefan, @Nastraughn, and myself

consider integrating with rclone

Consider integrating with rclone. The useful thing about rclone is that it can hold password information in hashed form. Also rclone mount seems to work well.

webdavfs and jupyter-fs is very slow

webdavfs and jupyter-fs is very slow. The issue is that jupyter-fs makes many calls to pyfilesystem and each call triggers a server connection to the webdavfs server. I am in the process of spending things up by putting caching into webdavfs.

Server connection problem running jupyter-fs in a jupyterhub deployment

I'm trying to use jupyter-fs in a JupyterHub deployment within a kubernetes cluster (Z2JH), but I get "404 (Not Found)" errors on startup of the JavaScript part of the extension. Here is Chrome's error message:

jupyter-fs-problem

The used docker image is based on jupyter docker stacks (https://github.com/jupyter/docker-stacks/blob/master/base-notebook/Dockerfile).There are no error messages in the SingleUserNotebook logs of the docker container. I use jupyter-fs==0.3.1 togther with jupyterlab==3.0.15 and jupyter-server==1.8.0. I followed the README and copied the "contents_manager_class" configuration in to the file "/etc/jupyter/jupyter_server_config.json".

Any ideas, why this connection error might happen? Is there some other configuration missing? Is it a kubernetes deployment issue?

Problems running jupyter-fs under jupyterhub

I'm having problems running jupyter-fs under jupyterhub. I have put the configuration file into /usr/etc/jupyter/jupyter_notebook_config.d but in the startup log I keep getting. Jupyter-fs seems to work when I run a notebook directly outside of the command line so I'm wondering if there is something involved with jupyterhub and the SingleUserNotebookApp that is causing the MetaManager to not get loaded.

[I 2020-09-05 08:15:54.625 SingleUserNotebookApp handlers:47] jupyter_tensorboar
d extension loaded.
/usr/lib/python3.8/site-packages/jupyterfs/extension.py:35: UserWarning: Misconf
iguration of MetaManager. Please add:

"NotebookApp": {
"contents_manager_class": "jupyterfs.metamanager.MetaManager"
}

to your Notebook Server config.

Use `fsspec` instead of `pyfilesystem2`

Before fsspec existed I used pyfilesystem2 and was very happy with it - it's a great library however it (apparently) didn't meet all the requirements for dask so fsspec was built, primarily to support dask, but it's also used in intake and as a generic filesystem api. As such it has a robust community around it and is continually improving and maturing.

Coming from the distributed computing world it has first-class support for cloud storage, and in particular (for my use-case) Azure Data Lake.

I haven't actually used the cloud storage plugins in pyfilesystem2 but they don't seem to have a lot of development momentum behind them, unlike fsspec.

To better support cloud filesystems I think it would be great if jupyter-fs could make use of fsspec rather than pyfilesystem2

race condition creates multiple entries

I'm having multiple entries for a file appear under a folder. What I think is happening is that something triggers a process to add new file items and because that is slow, some other process will cause the same entries to be added.

I think one solution is to fix the addition of buildTableContents. Instead of adding an entry, the code should check if an entry with an ID already exists, and replace if necessary.

Usage Question: How to Create New Notebook

As I am learning jupyter-fs, I have it working/running, and it seems to fit a specific need I have.

That said, I can't do one simple thing, and I don't know if I missing something obvious, or I have it misconfigured.

When I am in the normal Jupyterlab file browser, There are four options (New Launcher, New folder, Upload Files, and Refresh File list). However, when I am in the jupyter-fs, I see only three (Upload, New Folder, and Refresh). This appears to be the case on the screen shots as well. How can I get jupyter-fs to create a new Python 3 notebook in a location? This seems like a basic ask to be able to do a launcher, or am I missing something?

Support read-only FS

To improve the user experience, it would be great to be able to flag a filesystem as read-only. Ideally, the underlying FS would support the access pyfilesystem namespace, but for filesystems which don't (namely fs-s3fs: https://github.com/PyFilesystem/s3fs/blob/7f95af69e904e58b068ac4f6b39c2da488d5d918/fs_s3fs/_s3fs.py#L390-L418) being able to set the default to non-writable for the purpose of

try:
model['writable'] = info.permissions.check('u_w') # TODO check
except (errors.MissingInfoNamespace,):
# if relevant namespace is missing, assume writable
# TODO: decide if this is wise
model['writable'] = True
would prevent users from accidentally trying to rename or save files and receiving an error message.

Configuration could be something like:

{
  "resources": [
    {
      "name": "root at test dir",
      "url": "osfs:///Users/foo/test",
      "writable": True  // Not needed, as would default to True
    },
    {
      "name": "s3 test bucket",
      "url": "s3://test",
      "writable": False
    },
    {
      "name": "samba guest share",
      "url": "smb://[email protected]/test?name-port=3669"
    }
  ]
}

Getting lots of errors with typescript

../node_modules/@jupyterlab/apputils/node_modules/@types/react/index.d.ts:2978:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2978         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2982:14
    2982         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

../node_modules/@types/react-transition-group/node_modules/@types/react/index.d.ts:2981:14 - error TS2300: Duplicate identifier 'LibraryManagedAttributes'.

2981         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                  ~~~~~~~~~~~~~~~~~~~~~~~~

  ../node_modules/@types/react/index.d.ts:2982:14
    2982         type LibraryManagedAttributes<C, P> = C extends React.MemoExoticComponent<infer T> | React.LazyExoticComponent<infer T>
                      ~~~~~~~~~~~~~~~~~~~~~~~~
    'LibraryManagedAttributes' was also declared here.

../node_modules/@types/react-transition-group/node_modules/@types/react/index.d.ts:2992:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>', but here has type 'DetailedHTMLProps<AnchorHT../node_modules/@types/react-transition-group/node_modules/@types/react/index.d.ts:2992:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'a' must be of type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>', but here has type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>'.

2992             a: React.DetailedHTMLProps<React.AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>;
                 ~

  ../node_modules/@types/react/index.d.ts:2995:13
    2995             a: React.DetailedHTMLProps<React.AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>;
                     ~
    'a' was also declared here.

../node_modules/@types/react-transition-group/node_modules/@types/react/index.d.ts:2993:13 - error TS2717: Subsequent property declarations must have the same type.  Property 'abbr' must be of type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>', but here has type 'DetailedHTMLProps<HTMLAttributes<HTMLElement>, HTMLElement>'.

2993             abbr: React.DetailedHTMLProps<React.HTMLAttributes<HTMLElement>, HTMLElement>;
                 ~~~~

  ../node_modules/@types/react/index.d.ts:2996:13
    2996             abbr: React.DetailedHTMLProps<React.HTMLAttributes<HTMLElement>, HTMLElement>;
                     ~~~~
    'abbr' was also declared here.
MLAttributes<HTMLAnchorElement>, HTMLAnchorElement>'.

Using MetaContentsManager sets the working directory of all Python kernels to the root jupyterlab dir

For some reason if I set MetaContentsManager as my contents manager (as per the readme):

{
  "NotebookApp": {
    "contents_manager_class": "jupyterfs.meta_contents_manager.MetaContentsManager",
    ...
  }
}

then the working directory of all of my Python kernels gets set to my ~ dir, which is also my root jlab dir. Instead, I would in general expect the working directory of a notebook's kenel to be set to the containing dir of the notebook.

Do we know why that happens?

JupyterLab FS Wireframes

Hey folks! We’ve been working on some wireframes, and @tgeorgeux told me to quit being my Secretive Perfectionist Self and actually share some in-progress work so we can get your feedback. So, without further ado, some of my work - @emilythefan will follow-up with some of her designs, as well.

First, we’ve got a bit of exploration of where the file browser would live. Initially, keeping it in the sidebar as it currently is:
Main

This includes two different ways to have multiple file trees open. One, a split view, is accessed by option/alt-clicking on the ‘new window’ button, and opens in the lower half of the sidebar:
Split View

The other, by regular-clicking on the ‘new window’ button, pops a tab into the main content area:
Tabbed View

After that, some exploration of different interactions within the file tree. Starting with the ability to directly enter a directory path:
Directory Entry

The ‘folder’ icon, there, could pop a drop-down that shows the current path, as a stack:
Directory Stack

(As a side note, we’re looking at having a pseudo-directory, ‘above’ /, that contains all of the mounted drives/shares - a la /Volumes on macOS, which I hinted at in this alternate version:)
Directory Stack - All Drives

Finally, I’m a big fan of the ‘filter’ UI in Excel, so I shamelessly stole some of my favorite things about it in the ‘filter’ drop downs:
Filtering

First Install seems to require a build?

So I am using Anaconda, and I did a pip install. This is sorta a black box for me (based on my knowledge level, (i.e. how everything works with conda, when I do a pip install). Essentially, when the pip install finished, (btw, I did the pip install with the conda env activated). I then started jupyterlab in the env I installed, and the first startup items said:

[W 07:31:30.802 LabApp] Build recommended
[W 07:31:30.802 LabApp] jupyter-fs needs to be included in build

And then in JupyterLab I got a UI item that said it needed to be rebuilt. I clicked the "Rebuild" button, and it did some things and said:
[I 07:31:50.906 LabApp] Building jupyterlab assets (build:dev)
At the console.

After a while, I got another UI prompt and it said I needed to reload. Did that and carried on.

Is there anyway to do this automatically on install, or at least through the UI so the users don't have to do this? I am trying to make the process as automated as possible for users.

docmanager open

Opening S3 documents
I added this extension to my jupyterhub environment so that our users can have a visual files system for our s3 storage. The problem is we have our filebrowser's navigateToCurrentDirectory option set up to True and that results in the normal files browser navigating to the s3 directory when a user opens an s3 file due to the command you set up "docmanager: open". It would be amazing to differentiate between opening s3 files and normal files to avoid such behavior and not change the filebrowser context based on s3 context.

Server config: can't set contents_manager_class in jupyterfs.json

jupyterfs.json gets installed to <python-prefix>/etc/jupyter/jupyter_notebook_config.d/jupyterfs.json when you pip install the the jupyterfs Python package.

Ideally, jupyterfs.json should contain all of the server-side config needed to get jupyter-fs to work:

{
  "NotebookApp": {
    "contents_manager_class": "jupyterfs.metamanager.MetaManager",
    "nbserver_extensions": {
      "jupyterfs": true
    }
  }
}

However, in practice the "contents_manager_class" option gets ignored. Instead, "contents_manager_class" has to go in eg <python-prefix>/etc/jupyter/jupyter_notebook_config.json. Since I don't want to accidentally overwrite an existing jupyter_notebook_config.json, this limits my options in terms of automating the install of jupyter-fs.

Currently, the only truly reliable option is to have users manually add the appropriate "contents_manager_class" to their server config, but that leads to all kinds of problems for the average user, and also isn't automatic

UI for folders is a bit confusing

The UI is a bit confusing because it looks like the UI for the standard file manager. This encourages users to click on the text to activate an item rather than clicking on the folder icon.

The UI should be changed to match standard conventions for collapsible folders. There should be a right arrow for collapsed sections which should switch to a down arrow for non-collapsed sections.

replacing ContentsManager

Instead of trying to hack notebook's existing ContentsManager, we should replace it with something more flexible, based upon a more general notion of what "content" is. There are a number of popular projects on github that all have the aim of creating a spec for a virtual filesystem-ish thing. We should use one of the extant python options and/or take inspiration from the following:

Python

C++

  • cppfs
    • pro: we could write all of our filesystem backends in C++
    • con: we probably shouldn't

PHP

  • flysystem
    • Sadly, by far the best supported virtual filesystem library out there is 100% PHP, which is a bummer. Has a whole bunch of different filesystem implementations

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.