We should specify the minimum version for each requirement in setup.py:

requirements = [
    "flask",
    "flask-cors",
    "flask-socketio",
    "markdown",
    "numpy",
    "pandas",
    "python-dotenv",
    "pytz",
    "simple-websocket",
    "tzlocal",
    "backports.zoneinfo;python_version<'3.9'",
    "flask-talisman",
]

• taipy-core
• taipy-rest
• taipy-gui

Taipy should be able to run in Google Colab but the pip install is not working.

https://colab.research.google.com/

Description
Due to the introduction of _DataScopes, the render output in Page (PageRenderer) cannot be cached. Each time a new user comes in, the render methods is responsible for initializing all of the data in the user scopes. This is hugely unoptimized, but since the current approach has no visible impact on the performace, we might want to deal with this later down the line.

One possible solution to this problem is to cache the variable list and the expression list when the page is initiallly rendered and re-evaluated + apply to a new scope when a new user comes in.

Acceptance Criteria

• Ensure new code is unit tested, and check code coverage is at least 90%
• Propagate any change on the demos and run all of them to ensure there is no breaking change
• Ensure any change is well documented

• Update setup.py
• Rename version

Expose taipy.run method to run both gui and rest.

After pushing the taipy package on pypi we should test it to ensure the package works well and all components are correctly installed.

Moving structure to having src, make sure test succeed on both local and github with no import issue

Be able to run tests:

• Taipy-rest
• Taipy-airflow
• Taipy-entreprise
• Taipy

Expose the pb on a Friday meeting.

Watson Studio can not work with a Pandas version higher than 1.3.

Todo:

• Test if Pandas 1.3 works with Taipy-(core|Gui)
• Update both setup.py

@FabienLelaquais commented on Tue Sep 14 2021

After the packaging as been done, we must publish it for the world to see and use.

Release

• taipy-core 1.0.1
• taipy-gui 1.0.1
• taipy-rest 1.0.1

@florian-vuillemot commented on Mon Jan 31 2022

Provide documentation about Azure deployment. This doc is for a customer with an experiment in Azure.

Platforms target

• Container
• Webapp
• IAAS

Acceptance criteria

• Accessible for an Azure begginer
• Azure templating
• Security should be integrated

• Make production-planning demo public : https://github.com/Avaiga/demo-production-planning
• Ensure the following files are present.
  • Pipfile
  • LICENSE
  • INSTALLATION.md
  • CONTRIBUTING.md
  • CODE_OF_CONDUCT.md
  • .pre-commit-config.yaml
  • .license-header
  • README.md

Dosomething similar to

Avaiga/taipy-core#200

The code of "main.py" of a Taipy project is being re-runned by default on the Gui side with "use_reloader=True" (when a change is done to the code). It is also re-runned when a worker is created on the Core side. These behaviors could be changed or documented.

Because of this, it is also important to explain how to initialize the variables for the Gui in a good manner in order to get the desired result when the 'main.py' is being re-executed.

Version of Taipy:
taipy-core 1.1.1
taipy-gui 1.1.1

What would that feature address

Synthetical representation of complex datasets if am excellent feature to propose to end users: one simple
graphical object can represent a value, a trend, that can be understood in a glance.
We want to come up with a minimal set of easy-to-configure controls that can be used in such a Business User context.

Description of the ideal solution

A minimal set of highly customizable controls can be used just like any other control to represent such synthetic views of some data.

See if Plotly Express gauges could be a temporary workaround.

Acceptance Criteria

• Ensure new code is unit tested, and check code coverage is at least 90%
• Propagate any change on the demos and run all of them to ensure there is no breaking change
• Ensure any change is well documented

Migrate remaining taipy-legacy issues to the appropriate repository and archive taipy-legacy

@joaoandre-avaiga commented on Wed Dec 29 2021

@jrobinAV commented on Fri Feb 25 2022

@jrobinAV commented on Fri Feb 25 2022

@jrobinAV commented on Fri Feb 11 2022

The purpose is to have end2end testing of Taipy-core. We can take the opportunity of having taipy-rest to make it simpler to implement.

• Deploy an application
• Propose a test plan for testing each api independently + analyze behavior

Make Repositories public :

• taipy
• taipy-core
• taipy-rest
• taipy-gui
• taipy-doc
• taipy-getting-started

Today we have two workflow:

• release: tag and release Taipy on Github
• Publish: Publish the Taipy package on Pypi

We should merge both.

• taipy
• taipy-core
• taipy-gui
• taipy-rest

TODO:

• Can release only on an release branch -- check branch
• Fix typo: https://github.com/Avaiga/taipy-core/pull/153/files
• Remove tag deletion if not exists

Step 0:
We need to add to the release process the deployment of taipy on Conda.

• Taipy
• Taipy-core
• Taipy-gui
• Taipy-rest

First step: Deploy manually based on the documentation.

Second step: Start working on a proposal for automation.

Description
Refactoring of variable binding to ensure we manage what's get send to the front-end ...

Acceptance Criteria

• Ensure new code is unit tested, and check code coverage is at least 90%
• Propagate any change on the demos and run all of them to ensure there is no breaking change
• Ensure any change is well documented

The _run method does not return the result from the Gui or the Rest Flask app.
This does not allow us to expose it to a webserver as Gunicorn.

Our setup.py contains the minimal version needed for each dependence but not the maximal.
We should set the latest version that we are supporting to limit possible failure due to new interface on our dependencies.

Warning: Each package provide its own release process. Some packages break the interface between "patch" or "minor". We should notice this kind of behaviour to stay updated without breaking our installation.

Description

We should be able to make cycles start date be different from the default one.
Examples:
I want my Daily cycles to start at 8AM and not 12PM.
I want to have a business day frequency.
I want my monthly cycles to start on the 5th day of the month.
I want a business month frequency.
etc.

This link could help to understand the need.

What would that feature address

• Propose a way to filter scenarios by time period (start time - end time).

Outcome:

• Release Process for repositories.
• Process for releasing taipy-doc
• Release for taipy-getting-started 1.0.1. (with scenario_selector fix)
• Release for taipy-doc 1.0.0.

Create a release of taipy-getting-started with the same version as Taipy: v1.0.0

Would be nice to be able to filter data on displayed tables using an excel like method:
We could see the columns where filters apply:

One difficulty becomes that filters can be complex combinations (and/or) of formulas (for numbers or strings). We could certainly have a single formula in the first version!

Configure Taipy project and expose taipy-core, taipy-rest, taipy-guy APIs through Taipy project.

The goal is to be able to do a
pip install taipy
and just :

import taipy as tp

tp.gui
tp.configure_dtaa_node
...

• build project
• expose gui apis
• expose core apis
• expose rest apis (tp.rest) => Partial
• update milestone project to replcae import taipy.core as tp

In the Enterprise version, Taipy must propose a way to facilitate user authentication. This authentication must be shared by all components gui, core, rest, airflow, ...

• Propose a detailed design and architecture to implement authentication solution.
• Share the proposal in the team
• List all impacts on the existing implementation
• Create implementation tickets in github

We use the Jupyter notebooks from within Anaconda Navigator. We did a !pip install taipy inside the notebooks., but the
from taipy import Gui led to errors.

It seems that this problem only occurs on MacOS

Description

When calling tp.get_scenarios() or tp.get_primary_scenarios(), the user should be able to provide an optional field for sorting the scenarios.
The sort should be increasing or decreasing.
The sort could be on the name (default), id, creation_date, or tag.

I'm trying to create a simple data viz following the tutorial :
https://docs.taipy.io/getting_started/step_01/ReadMe/

from taipy import Gui

For info :

One of our customers needs to deploy its application on Windows server 2016 with Apache

Remove triggering milestone actions when pushing core PRs, and remove token secret on GitHub.

Description

• Expose methods in Job_manager to pause and resume a job from its id or the entity.

_JobManager.pause(job.id)
_JobManager.resume(job.id)
_JobManager.pause(job)
_JobManager.resume(job)

• Expose method in Taipy to pause and resume a job from its id or the entity.

tp.pause(job.id)
tp.resume(job.id)
tp.pause(job)
tp.resumue(job)

• Expose method in Job to pause and resume itself.

job.pause()
job.resume()

Acceptance Criteria

• Ensure new code is unit tested, and check code coverage is at least 90%
• Propagate any change in the demos and run all of them to ensure there is no breaking change
• Propagate any change in taipy-rest
• Ensure any change is well documented

@florian-vuillemot commented on Fri Jan 21 2022

We can help our customers to deploy with a Deployment tool.

Ex:

taipy deploy heroku
taipy deploy heroku docker
...

With prompt if needed.

@jrobinAV commented on Wed Dec 01 2021

@jrobinAV commented on Wed Jun 29 2022

from taipy import Config, Gui

import taipy as tp 

import time

def test(ini):
    print("Doing something")
    time.sleep(2)
    return ini

ini_cfg = Config.configure_data_node(id="ini_cfg", default_data=1)
final_cfg = Config.configure_data_node(id="final_cfg")

task_cfg = Config.configure_task(id="task_cfg", input=ini_cfg, output=final_cfg, function=test)

pipeline_cfg = Config.configure_pipeline(id="pipeline_cfg", task_configs=[task_cfg])
scenario_cfg = Config.configure_scenario(id="scenario_cfg", pipeline_configs=[pipeline_cfg])

md = "<|Run|button|on_action=create_and_submit|>"

def create_and_submit(state):
    tp.create_scenario(scenario_cfg).submit()
    print("Finished")

if __name__ == '__main__':
    tp.create_scenario(scenario_cfg).submit()
    Gui(md).run()

Airflow configs is still in the Taipy repository.
We should move it and allow Taipy config to call it.

Todo:

• Move Airflow config code in Taipy-airflow
• Move Airflow config tests in Taipy-airflow
• Update Airflow Config to be based on Properties and not class field
• Update Taipy to be based on properties and not Airflow config class field

Acceptance criteria

• No Airflow code should stay in Taipy
• Config interface should stay the same for end-user
• Tests should be moved in Taipy-Airflow

• Check if we need to specify the licence everywhere or just in the main file.
• Contributing section of the documentation

To be able to provide an easy display for the different shapes and forms of Pandas dataframes, there is a need to be able to display tables/dataframes with multiple indexes.
Either for the colonnes:

or for the rows:

See Th
There have been several requests on StackOverflow but it seems that there is a void there.

What would that feature address
It will address the fact that we are not able to connect two pipelines without using the Scenario Scope. It will make the configuration much easier and flexible for specific graph.

Description of the ideal solution
The ideal solution would be for Taipy to detect the scope of each Data node and make them accessible for the pipelines associated.

Here is an example of tasks (predict, evaluate) that are parallel to each other. To connect two pipelines (one pipeline for each task), we need 'pred' Data Nodes ('pred_pipeline_1','pred_pipeline_2', 'pred_pipeline_3') to have different names and a Scenario Scope.

The code of the graph above would be something like that

import taipy as tp
from taipy.core import Config, Scope

import pandas as pd

def evaluate(base_data):
    return base_data

def predict(base_data):
    return base_data

pipelines = ['pipeline_1', 'pipeline_2', 'pipeline_3']    
pipelines_cfg = []

for pipeline in pipelines:
    # put the data needed for each pipeline as their default data 
    parameters_cfg = Config.configure_data_node(id='parameters',
                                                   scope=Scope.PIPELINE)
    pred_cfg = Config.configure_data_node(id="pred"+pipeline,
                                                   scope=Scope.SCENARIO)
    task_pred_cfg = Config.configure_task(id=pipeline+"_pred",
                                     function=predict,
                                     input=parameters_cfg,
                                     output=pred_cfg)
    pipeline_pred_cfg = Config.configure_pipeline(id=pipeline+'_pred', task_configs=[task_pred_cfg])

    pipelines_cfg.append(pipeline_pred_cfg)

    evaluation_cfg = Config.configure_data_node(id='evaluation',
                                                scope=Scope.PIPELINE)
    task_evaluate_cfg = Config.configure_task(id=pipeline+"_pred",
                                     function=evaluate,
                                     input=pred_cfg,
                                     output=evaluation_cfg)
    pipeline_evaluate_cfg = Config.configure_pipeline(id=pipeline+'_evaluate', task_configs=[task_pred_cfg])

    
    pipelines_cfg.append(pipeline_evaluate_cfg)

                                     
scenario_cfg = Config.configure_scenario(id="scenario_1", pipeline_configs=pipelines_cfg)

The goal would be to simplify this by having a Shared Scope. The name would not be different, it will be easier to manage data and the Scope would be at the appropriate level

The code of the graph above would be something like that:

import taipy as tp
from taipy.core import Config, Scope

import pandas as pd

def evaluate(base_data):
    return base_data

def predict(base_data):
    return base_data

pipelines = ['pipeline_1', 'pipeline_2', 'pipeline_3']    
pipelines_cfg = []

# put the data needed for each pipeline as their default data 
parameters_cfg = Config.configure_data_node(id='parameters',
                                               scope=Scope.PIPELINE)
pred_cfg = Config.configure_data_node(id="pred",
                                               scope=Scope.SHARED)
    
task_pred_cfg = Config.configure_task(id='pred_task',
                                      function=predict,
                                      input=parameters_cfg,
                                      output=pred_cfg)
    
pipeline_pred_cfg = Config.configure_pipeline(id='pipeline_pred', task_configs=[task_pred_cfg])

evaluation_cfg = Config.configure_data_node(id='evaluation',
                                            scope=Scope.PIPELINE)
    
task_evaluate_cfg = Config.configure_task(id=pipeline+"_evaluate",
                                 function=predict,
                                 input=pred_cfg,
                                 output=evaluation_cfg)
    
pipeline_evaluate_cfg = Config.configure_pipeline(id='pipeline_evaluate', task_configs=[task_evaluate_cfg])

scenario_cfg = Config.configure_scenario(id="scenario_1", pipeline_configs=[pipeline_pred_cfg]*len(pipelines)+
                                                                            [pipeline_evaluate_cfg]*len(pipelines))    

There is no for loop and the name of the Data Nodes is the same. However, with this code, it is not possible to understand what the user wants to execute with the pipeline_configs and which pipelines have access to which Data Nodes.

Caveats
It would impact how the configuration and the access to the entities, and so on.

Python -- taipy-auth

• Boostrap the repos
• Support to authentication validator (LDAP, OAuth2)
• Tests

Front-end

• To investigate -- token for ex

ow, we can update the values of each cell of a table (Those that are editable).
Could we also add a row?