v1.2.0 update

[sfc-gh-jfreeberg]

• Add setup.py and incorporate it with environment.yml: Removes a lot of the sys methods that were used to set the path
• Sproc now returns a table
• Test case for sproc updated for new return type

Still an open question regarding importing UDFs into sproc

[sfc-gh-mrojas]

I see that before we had instructions for virtualenv wont we support that? Still a lot of users use virtualenv

[sfc-gh-klin]

I'm also torn between the prescriptivism of recommending just conda or also keeping in instructions for virtualenv, since we do have that mentioned in our docs.

[sfc-gh-klin]

For the VS Code integration we went with just conda for simplicity of ensuring environment similarity.

[sfc-gh-jfreeberg]

Also torn, my concern was that if someone wants to use a package from PyPi when they deploy to the Snowflake server, the package will come from Conda. So I figured it'll be good to get them on the Conda train sooner so their packages are consistent

[sfc-gh-mrojas]

wouldn't it be better if we setup the settings in .vscode/settings.json

I typically use:

{

"python.envFile": "${workspaceFolder}/.env",
"files.exclude": {
    "**/.git": true,
    "Lib": true,
    "Include": true,
    "Scripts": true,
    "**/__pycache__":true
}   

}

[sfc-gh-jfreeberg]

I don't follow how those settings relate to the imports you highlighted

[sfc-gh-mrojas]

Sorry let me see if I can explain this better. If you use settings.json file like this:

{
    "python.envFile": "${workspaceFolder}/.env",
    "terminal.integrated.env.linux": {"PYTHONPATH":"${workspaceFolder}/src:${workspaceFolder}/test:${PYTHONPATH}"},
    "terminal.integrated.env.osx": {"PYTHONPATH":"${workspaceFolder}/src:${workspaceFolder}/test:${PYTHONPATH}"},
    "terminal.integrated.env.windows": {
        "PYTHONPATH": "${workspaceFolder}\\src:.\\test:${PYTHONPATH}"
    },
    "python.testing.pytestArgs": [
        "test"
    ],
    "python.testing.unittestEnabled": false,
    "python.testing.pytestEnabled": true,
    "python.analysis.extraPaths": [
        "${workspaceFolder}/src"
    ]
}

that configures the tooling to understand that all the code is under ./src/ so you dont have to include src as part of the import which can be confusing. This also works with the debugger and whenever you open a terminal.

[sfc-gh-mrojas]

If you combine that with some changes in the setup.py like:

from setuptools import setup, find_packages

PACKAGE_NAME = "project1"
setup(
    name=PACKAGE_NAME,
    version="0.1.0",
     # Specify the package directory
    package_dir={'': 'src'},
    # Include all files from the src directory
    package_data={PACKAGE_NAME: ['*']}
)

then you can just do python setup.py bdist_wheel and you can just renamed that whl to .zip and it will work for deployment

[sfc-gh-klin]

This could also be

RETURNS TABLE()

if you think that the simplicity and guiding users to realize they don't need to specify all the columns in the table is nice.

[sfc-gh-jfreeberg]

Good catch, I could have sworn when I tried without the type params the SQL would fail. Let me retry

[sfc-gh-mrojas]

I would recommend using somethign like:

import functions and then
functions.__file__

mostly because that makes the code lets susceptible to path changes. However for that to work well you need to properly setup PYTHONPATH that is why the suggestions in settings.json

[sfc-gh-jfreeberg]

Fixed, ran locally fine. Going through PR checks now

[sfc-gh-jfreeberg]

@sfc-gh-mrojas -- CI is breaking for some reason, filed an issue here: snowflakedb/snowpark-python#992