Below are some commonly asked questions by ActiveState users. If you have questions please check the online community forums. They are regularly maintained by ActiveState staff and are contributed to by other members of the ActiveState community. For questions related to your account, reach out to contact us.
Your ActiveState project will not use any first-party or proprietary code produced by you or anyone else with whom you have shared the project. All user-generated code does not become part of the shared properties of your project, nor does it belong to ActiveState.
Details on how to share your project can be found here.
The benefits of sharing your ActiveState project include
No, the invite email is specific to your email address and your organization. If you would like to provide access to other people in your organization you can either sign up for the Platform yourself and invite them, or contact us with the email addresses of the users to invite, and we will send them individual invites (this is only available for paid tiers).
The time needed to build your project can vary depending on
A small build with fewer packages and dependencies may only take seconds or minutes to build successfully. Larger, more complex projects can take several minutes or even hours to build successfully.
In cases where a build process appears stuck, try resetting the build by making a minor change to your configuration. For example, changing the version of an existing package, adding a new package, changing the version of the language, etc.
A Common Vulnerability and Exposures (CVE) identification is the unique identifier that is given to a specific vulnerability by the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD). Each CVE has been reviewed by a governing body (the CVE Numbering Authority) and found to present a credible threat to the security of a system. Check here to find out more about CVEs and how the ActiveState Platform and the State Tool deal with them.
Organizations are the way you group ActiveState Platform projects for a company, department, or team. Members of the organization will have access to each project in the organization, with the ability to invite others to join, remove users, and create or modify runtimes (depending on the role of the user).
You can create paid organizations that support both private and public projects, or free organizations that only support public projects.
Komodo IDE and Komodo Edit have been opensourced. Check out our blog article to find out more.
All current license agreements can be found here, and agreements for older versions or legacy products can be found here.
Information on deprecated products and languages can be found on the ActiveState documentation homepage. These docs are for archival use only and are not updated.
Details on how to delete your account can be found here. Note that deleting your account will not automatically uninstall the State Tool from your machine.
Each runtime is created and executed in a virtual environment that will avoid conflicts between other projects, production environments, and the developer environments of other developers (if the runtime has been shared). Using the ActiveState Platform, each runtime can be easily updated to include the most current and secure versions of all dependencies/packages/binaries/etc.
Instead of offering a pre-packaged downloadable installer, the State Tool creates a virtual environment on your system allowing you to run concurrent and disparate development environments that contain all (and only) the packages you need for your projects, without conflicts or interfering with the preexisting language versions on your system.
Installers are available for Enterprise tier users. Click here to find out more
Each ActiveState project (and the associated runtime) is installed in its own virtual directory to prevent dependency conflicts. When you activate a runtime you’re setting up a virtual environment to work from. This keeps your dependencies separate from those outside of the virtual environment’s parameters. This is important because
After exiting your runtime, files are cached on your local system until deletion. This helps keep reloading time fast. Regularly using the state pull command will keep your project, and its virtual environment, up to date on your local installation.
You can end your activated state by typing exit into the command prompt or terminal window. Closing the command prompt or terminal window will also deactivate your project.
You can find instructions for location-specific installations in the checkout documentation here.
ActiveState currently has integrations with several popular IDE’s including Visual Studio Code, Pycharm, and Eclipse. More information about integrations can be found here.
For organizations with Service Level Agreements (SLA), use the contact information included in your SLA to request specific packages. When requesting a new package, include the name of your organization and project, as well as the package and, when possible, the package version.
Users without an SLA can post a request on the community forums. Feel free to include as much information as you feel comfortable disclosing, including your organization or project name, and package version. These requests will be processed according to their availability and user demand.
Organizations with SLAs are encouraged to use the contact information provided in their agreement to receive assistance from ActiveState. Users without an active SLA can try to review and edit any CVEs that may be causing the build to fail, or ask for help on the community forums.
After making changes to your project using the Platform, open the project using the State Tool by starting a shell or activating the project. Then run state pull. This will update your project with the changes made on the Platform.
If you experience trouble installing your runtime, make sure that the OS version on your local machine meets the minimum standards.
Instructions on how to download the files from your project can be found here.
The recommended version of each language is based on Platform build success rates and the availability of new open source package versions. ActiveState continuously updates these recommended versions as more recent versions of the language ecosystem become stable and vetted by the open source community.
Open your command prompt or terminal and type state update
To check out a project on your local machine enter state checkout <orgname>/<projectname> <path to folder>
For example state checkout JohnSmith/Project1 C:\project
To check out a project’s bits to your local machine enter state checkout <orgname>/<projectname> --runtime-path <path to folder>
For example state checkout JohnSmith/Project1 --runtime-path C:\project
To display all existing projects, their location on your system, and the location of their executable files enter state projects.
Working from your project directory (the folder containing your activestate.yaml file) enter the command state pull.
You can use the State Tool to check your current project for any potential vulnerabilities by activating the project and running state cve to view the vulnerabilities associated with that project.
For a more detailed explanation of the vulnerabilities associated with your project, enter state cve report. This will include an ID for each listed vulnerability so you can look them up to see how they may impact the security or performance of your project. To address the vulnerabilities found in your project see here.
state projects in your terminal to view a list of the projects that are installed locally on your machine.exit into the command line. This will deactivate your project.state activate <orgname/projectname> to activate the project you want to switch to.You can end your activated state by typing exit into the command prompt or terminal window. Closing the command prompt or terminal window will also deactivate your project.
Comparing different versions of the same project is a great way to make sure changes have been logged and to track the progress of your projects. To compare two separate projects:
state activate <organization1/project1> into your command prompt.state run <script1>.exit to deactivate the project.state activate <organization1/project2> into the command prompt.state run <script2> and wait for the script to stop.There are two separate commands to uninstall your activated project, each with unique characteristics.
state clean cache will remove all copies of cached versions of everything and reset the State Tool cache. This command will not uninstall the State Tool. This needs to be done from the main project directory, although it may work from other directories with newer language versions.state clean uninstall gets rid of cached files, uninstalls the State Tool, installed language runtimes, and all configured information. It’s important to note that after confirming your choice to run this command, you will need to restore everything from the Platform. To find out more see here.If you are updating from a much older version it may have problems with runaway services that may be preventing the update. The State Tool Troubleshooting section has instructions on identifying and shutting down runaway services for Windows, macOS, and Linux. After running the script to stop ongoing processes, enter state update to resume your update.
Generally, the “could not figure out what path to use” means that the State Tool can’t find a suitable folder for your runtime. Unsuitable folders include program folders, system folders, or folders where restrictive permissions have been set. Your personal folders are more likely to be writable and are a better choice for your project. Follow the steps here to check out a project to a specific location on your system.
If you receive this error, you can try resolving the error in the Platform. The Platform provides more feedback and can see if (and when) the rebuild succeeds. That will show when the State Tool can find a working build of the module to download from your project.
The Platform will also allow you to specify the package version and see immediately if there are any vulnerabilities associated with it. Check here for more information about adding packages using the Platform and here for information about vulnerabilities.
The State Tool cannot download Tcl projects, you must go to the Platform and download the .msi or .tar file directly from the project page to install your Tcl project on your local machine.
To install the State Tool on a server you will need to checkout the project to a specific location on the server. To do so enter state checkout <orgname>/<projectname> <location>. This will place a project folder containing your project’s activestate.yaml file into the specific location. To checkout all of the bits associated with your project enter state check out <orgname>/<projectname> --runtime-path <location>. More information on state checkout can be found here.
This error may indicate that your current working directory is incompatible with the State Tool (for example a System32 or similar directory), or you are trying to state activate as an Admin on your local system. After activating, your runtime will be installed into a personal (or user) AppData folder. Only users can access the runtime. Try exiting as an Admin, logging in as a user, and re-activating the runtime.
This error may result from trying to install a package while being behind a proxy server. Click here for more details and potential solutions